All perguntas(dba)

DO $$
DECLARE
    rec RECORD;
    outcome BOOLEAN;
    rule TEXT;
BEGIN
    -- Assume the record references a single row that contains the columns under test in the rule
    rule := 'columnA > 30 OR columnB < 50';
END;
$$
 LANGUAGE plpgsql;

Aqui está um bloco conciso com um exemplo da regra que gostaria de avaliar em relação ao registro. Imagino que precise de EXECUTEuma instrução SQL dinâmica.

Quero determinar o tipo do registro dinamicamente em tempo de execução, pois tenho acesso fácil a outra string com o nome da tabela. Eu imaginei lançar para table_name%ROWTYPE. Pelo que entendi, não consigo converter dinamicamente um RECORD para um tipo composto em tempo de execução.

Pensei então em usar row_to_json(rec), mas precisaria avaliar a regra em relação a esse objeto JSON. Não estou familiarizado com como fazer isso em PL/pgSQL.

Estou buscando de um CURSOR para um RECORD porque quero um iterador que possa passar para diferentes funções que não tenha a sobrecarga de uma TEMPORARY TABLE. Sou bastante novo em PL/pgSQL, diria apenas alguns milhares de LOC na linguagem, então ainda estou aprendendo como trabalhar com suas estruturas de controle. Estou pensando que talvez precise fazer backup um pouco e escolher diferentes controles e/ou estruturas de dados para o problema. Como você abordaria esse problema?

Servidor de origem: 1 tabela - InnoDB -> 700gb - 1,5 bilhão de registros (Espaço livre em disco: 200gb)

O servidor de destino está na mesma rede.

O servidor de destino terá muito espaço livre, a origem só tem 200gb livres.

1 – A tabela possui 1,5 bilhão de registros, então consultar linha por linha não seria o melhor caminho.

2 - Possivelmente a única forma viável que encontrei no momento foi copiar o arquivo IBD e tentar restaurá-lo utilizando TABLESPACE, conforme instruções neste link: https://community.spiceworks.com/t/recover-mysql- banco de dados de arquivos frm e ibd/1014394

Com o MariaBackup eu conseguiria salvar o arquivo na fonte se tivesse espaço livre. Infelizmente não é possível enviar o arquivo via MariaBackup diretamente para o servidor de origem pela rede, certo?

Existe alguma forma melhor de exportar além dessas duas citadas?

Muito obrigado. =)

Eu tenho uma instância nomeada instalada e configurada para usar a porta TCP 1433 em vez de portas dinâmicas. O navegador SQL está em execução e o TCP IP está ativado. Tenho que colocar o número da porta 1433 no ssms e sem incluir o número da porta ele não conecta. Por favor, aconselhe o que estou perdendo aqui. Isso é um problema de firewall ou estou faltando alguma coisa.

Ultimamente, tenho lutado para saber como o TWCS funciona especificamente. Em nosso fluxo de trabalho, temos algumas tabelas contendo dados de série temporal com um TTL principalmente estático. Como tal, foi tomada a decisão de utilizar o TWCS como estratégia de compactação para este efeito. Existem, no entanto, infelizmente algumas destas tabelas que parecem estar a ocupar mais espaço do que o habitual, ou seja, parecem estar bloqueadas pelas SSTables mais antigas. Já identificamos uma causa raiz potencial. Existe um cenário em que uma reescrita de TTL pode ocorrer em um registro existente, por exemplo, diminuindo o TTL desse registro existente. Nesse cenário, faz sentido que esse registro, que residiria em vários SSTables, com TTL maior e menor, bloqueie a compactação de outros SSTables. Na verdade, depois de um tempo, esses registros atualizados apareceram no TTL e, posteriormente, tudo foi desbloqueado. No entanto,

Por isso comecei a ler alguns artigos sobre isso. Alguns artigos aos quais me refiro são, por exemplo, https://thelastpickle.com/blog/2016/12/08/TWCS-part1.html ou https://www.redshots.com/cassandra-twcs-must-have-ttls/ . Especialmente este último me causou suspeitas sobre se uma alteração de TTL entre "novos" registros também teria um efeito de bloqueio. O último artigo menciona especificamente que a exclusão de todo o sstable quando preenchido com TTLs só acontecerá se for o sstable mais antigo, portanto, uma vez que um não pode ser excluído, nenhum dos subsequentes também poderá ser excluído .

Consideramos o seguinte cenário com TWCS:
Escrevemos, por exemplo, 100 registros com um TTL de 5.000, que terminam todos na mesma SSTable e, posteriormente, escrevemos 100 novos registros com um TTL diferente de 100, gravados em uma nova coluna (mas talvez a mesma partição).
Com base em meus testes, presumo que os primeiros 100 registros para "saída TTL" não liberarão nenhum espaço em disco até que o SSTable que contém os registros com o TTL mais antigo expire.

No entanto, eu não estava totalmente confiante sobre isso, especialmente porque ambos os SSTables não contêm essencialmente nada que deveria estar obscurecendo um ao outro. Como tal, não acredito que deva haver uma razão lógica para que essas tabelas não sejam removidas do disco. Além disso, também considerei a possibilidade de dados TTL mais antigos e mais recentes serem misturados na SSTable mais antiga. Presumi que isso também se comportaria da mesma forma. Em geral, as dúvidas permaneceram. Como tal, queria validar esta conclusão.

Resumindo: com o TWCS, a remoção do disco de um novo registro com TTL mais baixo será bloqueada por qualquer registro mais antigo com TTL mais alto residente em uma SSTable diferente?

Temos alguns bancos de dados SQL Server que precisam ter uma opção confiável definida como 'ON' para permitir o carregamento de assemblies externos, mas sempre que há algum patch de segurança, a opção é desativada e o aplicativo é interrompido.

Não quero criar vários trabalhos de agente SQL para executar o set trustworthy oncomando constantemente, então estou tentando desenvolver um cursor que execute esse comando nos cinco bancos de dados.

Isso é o que tenho agora, mas estou recebendo um erro ao dizer que confiável não é uma opção SET reconhecida. Alguém poderia dar uma olhada e ajudar a consertar isso?

Executando no SQL Server 2019 Enterprise Edition.

Declare @db_name varchar (100)
Declare @command nvarchar (200)
Declare database_cursor cursor for
Select name from master.sys.sysdatabases
Where name in ('db1', 'db2', 'db3', 'db4', 'db5')

Open database_cursor

Fetch next from database_cursor into @db_name
While @@fetch_status = 0

Begin
     Select @command = 'ALTER DATABASE' + ''''+ @DB_NAME+ '''' + 'SET TRUSTWORTHY ON'
PRINT @COMMAND
EXEC SP_EXECUTESQL @COMMAND

FETCH NEXT FROM DATABASE_CURSOR INTO @DB_NAME
END

CLOSE DATABASE_CURSOR
DEALLOCATE DATABASE_CURSOR

Sou novo em exportação/importação de banco de dados (já que não sou DBA) e recentemente fui encarregado de desenvolver um script de limpeza que inclui a subtarefa de exportação de bomba de dados (expdp).

Mas, por alguns motivos, quando executo o comando expdp e verifico o arquivo de log, às vezes aparece esse erro.

ORA-31693: Table data object "<schema>"."<table_name>":"<SYS_P...sth>" failed to load/unload and is being skipped due to error:
ORA-00942: table or view does not exist

E às vezes mostra esse tipo de log (pode exportar, mas de alguma forma exporta 0 linhas com um pouco de espaço de memória)

. . exported "<schema>"."<table_name>":"<SYS_P...sth>"     .. KB 0 rows

Alguém pode me ajudar o que causou o problema ou onde devo dar uma olhada no comando?

Observe que a tabela e os dados existem no banco de dados (mesmo esquema que uso para consultar os dados normalmente), pois posso consultar e verificar os dados e a contagem de linhas.

Os documentos insistem que ISNULLé uma função, mas COALESCEnão é. Especificamente, eles dizem

A função ISNULL e a expressão COALESCE

Se eu colocar meu chapéu Lisp, posso pensar nisso COALESCEcomo uma macro e tudo faz sentido. No entanto, nunca precisei de tal pensamento no T-SQL. Então, devo perguntar. Em T-SQL:

1. Qual é a definição de uma função?
2. Qual é a definição de uma expressão?
3. Como posso saber a diferença entre uma função e uma expressão?

Existe uma maneira no banco de dados PieCloudDB de dividir um dado em vários dados com base na hora de início e de término em dias. Por exemplo:

Saída:

Caso você não conheça o PieCloudDB, você pode usar o PostgreSQL como banco de dados de teste.

Eu tenho a seguinte consulta que leva cerca de 5 segundos para ser concluída, costumava ser 0,5s, depois 1s, 2s agora estamos em 5s, apesar do fato de a quantidade de dados no banco de dados não ter mudado! Esta consulta faz um select para obter uma porção de dados para processar e atualizar algumas colunas (nenhuma nova linha é adicionada), normalmente tem um "limite 500" mas o tempo de consulta com "limite 1" e "limite 500" é o mesmo, então pela simplicidade mudei esse post para "limite 1".

Fiz uma cópia da tabela de produção no mesmo servidor para poder executar vários testes e alterações sem prejudicar os dados de produção, também alguns dados foram ofuscados mas todas as consultas e suas saídas são reais

A tabela “teste” possui 34 milhões de linhas e tamanho de 11,3 GB, cujo índice é de 3,3 GB. O servidor é Freebsd 13.2, mysql 8.0.35 em um drive Samsung nvme bastante decente, 64 GB de RAM e innodb_buffer_pool_size = 42G. O servidor não está trocando e tem quase 4 GB de memória livre. Há uma grande quantidade de carga de IO de disco proveniente de consultas para outros bancos de dados hospedados no mesmo servidor (e provavelmente principalmente log binário porque este é o mestre de replicação), no entanto, se eu desabilitar todas as outras consultas e executar apenas a consulta em questão, o tempo de execução é exatamente o mesmo.

A consulta lenta:

SELECT t_channel_id,login FROM test WHERE t_channel_id IS NOT NULL AND videos_scanned IS NULL AND videos_scanned_lock=0 limit 1;
+--------------+---------------+
| t_channel_id | login         |
+--------------+---------------+
| 933271419    | sunday1funday |
+--------------+---------------+
1 row in set (4.43 sec)

O índice é usado corretamente e cobre todas as colunas WHERE. Se eu remover a coluna videos_scanned_lock da consulta, o tempo será de 0,35s (ainda lento, mas muito mais rápido) se eu remover APENAS a coluna t_channel_id da consulta, o tempo será 0s

Eu tenho uma teoria de por que o tempo era muito mais rápido no início e agora está em torno de 5s. Agora estamos processando registros em torno de 30 milhões de linhas (de 34) e no início as linhas selecionadas eram do início da tabela e agora tipo “quase toda a tabela tem que ser verificada primeiro para chegar aos resultados”. Mas 34 milhões de registros são muito para o MySQL? Suponho que não, a tabela inteira tem menos de 1/4 do tamanho do buffer innodb. Como prova desta teoria, no parágrafo anterior escrevi que se eu remover a coluna t_channel_id da consulta, o tempo será 0s – isso porque se eu remover esta coluna serão mostrados resultados desde o início da tabela. A segunda prova, é que a consulta dá certo resultado, se eu alterar o valor de t_channel_id deste resultado para um número muito menor, o tempo de consulta será muito menor (porque com um ID menor ele será encontrado mais cedo). Tenho certeza de que respondi minha própria pergunta, MAS por que isso está acontecendo? Acredito que algo deve estar configurado incorretamente, mas não consigo encontrar o que é e espero encontrar uma resposta aqui. Qualquer dica para melhorar esta situação será apreciada :)

Abaixo, forneço dados de depuração: mostre criar tabela, criador de perfil, descreva análise e my.cnf

SHOW CREATE TABLE test;

CREATE TABLE `test` (
  `channel_id` bigint NOT NULL AUTO_INCREMENT,
  `t_channel_id` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_bin DEFAULT NULL,
  `login` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL,
  `display_name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL,
  `videos_scanned` datetime DEFAULT NULL,
  `videos_scanned_lock` int NOT NULL DEFAULT '0',
  PRIMARY KEY (`channel_id`) USING BTREE,
  UNIQUE KEY `login` (`login`),
  KEY `t_channel_id_2` (`t_channel_id`,`videos_scanned`,`videos_scanned_lock`)
) ENGINE=InnoDB AUTO_INCREMENT=34626837 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

describe SELECT t_channel_id,login FROM test WHERE t_channel_id IS NOT NULL AND videos_scanned IS NULL AND videos_scanned_lock=0 limit 1;
+----+-------------+-------+------------+-------+----------------+----------------+---------+------+----------+----------+-----------------------+
| id | select_type | table | partitions | type  | possible_keys  | key            | key_len | ref  | rows     | filtered | Extra                 |
+----+-------------+-------+------------+-------+----------------+----------------+---------+------+----------+----------+-----------------------+
|  1 | SIMPLE      | test  | NULL       | range | t_channel_id_2 | t_channel_id_2 | 1023    | NULL | 16992061 |     1.00 | Using index condition |
+----+-------------+-------+------------+-------+----------------+----------------+---------+------+----------+----------+-----------------------+

describe analyze SELECT t_channel_id,login FROM test WHERE t_channel_id IS NOT NULL AND videos_scanned IS NULL AND videos_scanned_lock=0 limit
1;
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                                                                                                                                                                                                                                             |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| -> Limit: 1 row(s)  (cost=7.65e+6 rows=1) (actual time=4407..4407 rows=1 loops=1)
    -> Index range scan on test using t_channel_id_2 over (NULL < t_channel_id), with index condition: ((test.videos_scanned_lock = 0) and (test.t_channel_id is not null) and (test.videos_scanned is null))  (cost=7.65e+6 rows=17e+6) (actual time=4407..4407 rows=1 loops=1)
 |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (4.41 sec)

SET profiling = 1;
Query OK, 0 rows affected, 1 warning (0.00 sec)

SELECT t_channel_id,login FROM test WHERE t_channel_id IS NOT NULL AND videos_scanned IS NULL AND videos_scanned_lock=0 limit 1;
+--------------+---------------+
| t_channel_id | login         |
+--------------+---------------+
| 933271419    | sunday1funday |
+--------------+---------------+
1 row in set (4.43 sec)

show profile cpu;
+--------------------------------+----------+----------+------------+
| Status                         | Duration | CPU_user | CPU_system |
+--------------------------------+----------+----------+------------+
| starting                       | 0.000142 | 0.000372 |   0.000036 |
| Executing hook on transaction  | 0.000063 | 0.000048 |   0.000004 |
| starting                       | 0.000027 | 0.000022 |   0.000002 |
| checking permissions           | 0.000028 | 0.000025 |   0.000003 |
| checking permissions           | 0.000018 | 0.000016 |   0.000001 |
| Opening tables                 | 0.000098 | 0.000094 |   0.000009 |
| init                           | 0.000025 | 0.000019 |   0.000002 |
| System lock                    | 0.000026 | 0.000024 |   0.000002 |
| optimizing                     | 0.000091 | 0.000084 |   0.000008 |
| statistics                     | 0.000284 | 0.000269 |   0.000026 |
| preparing                      | 0.000126 | 0.000119 |   0.000011 |
| executing                      | 4.426675 | 6.156588 |   0.156978 |
| end                            | 0.000016 | 0.000005 |   0.000001 |
| query end                      | 0.000004 | 0.000003 |   0.000000 |
| waiting for handler commit     | 0.000005 | 0.000005 |   0.000001 |
| closing tables                 | 0.000006 | 0.000006 |   0.000000 |
| freeing items                  | 0.000010 | 0.000014 |   0.000002 |
| logging slow query             | 0.000027 | 0.000020 |   0.000001 |
| cleaning up                    | 0.000008 | 0.000007 |   0.000001 |
+--------------------------------+----------+----------+------------+
19 rows in set, 1 warning (0.00 sec)

[mysqld]
user                            = mysql
port                            = 3306
socket                          = /tmp/mysql.sock
bind-address                    = 0.0.0.0
datadir                         = /var/db/mysql
log-output                      = FILE
relay-log-recovery              = 1
slow-query-log                  = 1
server-id                       = 29
sync_binlog                     = 1
sync_relay_log                  = 1
binlog_cache_size               = 16M
binlog_expire_logs_seconds      = 43200
default_password_lifetime       = 0
enforce-gtid-consistency        = 1
gtid-mode                       = On
safe-user-create                = 1
lower_case_table_names          = 1
explicit-defaults-for-timestamp = 1
myisam-recover-options          = BACKUP,FORCE
table_open_cache                = 16384
table_definition_cache          = 8192
net_retry_count                 = 16384
key_buffer_size                 = 256M
max_allowed_packet              = 64M
long_query_time                 = 0.2
innodb_buffer_pool_size         = 42G
innodb_data_home_dir            = /var/db/mysql
innodb_log_group_home_dir       = /var/db/mysql
innodb_data_file_path           = ibdata1:128M:autoextend
innodb_temp_data_file_path      = ibtmp1:128M:autoextend
innodb_flush_method             = O_DSYNC
innodb_log_buffer_size          = 32M
innodb_write_io_threads         = 12
innodb_read_io_threads          = 12
innodb_autoinc_lock_mode        = 2
innodb_redo_log_capacity        = 8192M
log_error                       = /var/db/mysql/mysql-error.log
slow_query_log_file             = /var/db/mysql/mysql-slow.log
skip_name_resolve
mysqlx                          = 0
tls_version                     = TLSv1.2
innodb_flush_log_at_trx_commit  = 0
replica_parallel_workers        = 1
binlog_group_commit_sync_delay  = 10000

Editar para Ergest:

...
KEY `channel_id` (`videos_scanned_lock`,`channel_id`,`t_channel_id`) USING BTREE

SELECT t_channel_id,login FROM test force index (channel_id) WHERE t_channel_id IS NOT NULL AND videos_scanned IS NULL AND videos_scanned_lock=0 limit 1;
+--------------+----------------+
| t_channel_id | login          |
+--------------+----------------+
| 921437844    | marryme2       |
+--------------+----------------+
1 row in set (50.80 sec)

describe SELECT t_channel_id,login FROM test force index (channel_id) WHERE t_channel_id IS NOT NULL AND videos_scanned IS NULL AND videos_scanned_lock=0 limit 1;
+----+-------------+-------+------------+------+---------------+------------+---------+-------+-------+----------+------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key        | key_len | ref   | rows  | filtered | Extra                              |
+----+-------------+-------+------------+------+---------------+------------+---------+-------+-------+----------+------------------------------------+
|  1 | SIMPLE      | test  | NULL       | ref  | channel_id    | channel_id | 4       | const | 68378 |     9.00 | Using index condition; Using where |
+----+-------------+-------+------------+------+---------------+------------+---------+-------+-------+----------+------------------------------------+
1 row in set, 1 warning (0.00 sec)

describe format=json SELECT t_channel_id,login FROM test force index (channel_id) WHERE t_channel_id IS NOT NULL AND videos_scanned IS NULL AND videos_scanned_lock=0 limit 1;
....
 {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "2094461.53"
    },
    "table": {
      "table_name": "test",
      "access_type": "ref",
      "possible_keys": [
        "t_channel_id_2",
        "channel_id"
      ],
      "key": "channel_id",
      "used_key_parts": [
        "videos_scanned_lock"
      ],
      "key_length": "4",
      "ref": [
        "const"
      ],
      "rows_examined_per_scan": 16992061,
      "rows_produced_per_join": 1529285,
      "filtered": "9.00",
      "index_condition": "(`db`.`test`.`t_channel_id` is not null)",
      "cost_info": {
        "read_cost": "395255.43",
        "eval_cost": "152928.54",
        "prefix_cost": "2094461.53",
        "data_read_per_join": "4G"
      },
      "used_columns": [
        "t_channel_id",
        "login",
        "videos_scanned",
        "videos_scanned_lock"
      ],
      "attached_condition": "(`db`.`test`.`videos_scanned` is null)"
    }
  }
} |

Para @Rick James

Simplesmente não funciona

show create table test;
....
KEY `t_channel_id` (`t_channel_id`,`login`,`videos_scanned`,`videos_scanned_lock`)

SELECT t_channel_id,login FROM test force index (t_channel_id) WHERE t_channel_id IS NOT NULL AND videos_scanned IS NULL AND videos_scanned_loc
k=0 limit 1;
+--------------+----------------+
| t_channel_id | login          |
+--------------+----------------+
| 921437844    | blahblahcar |
+--------------+----------------+
1 row in set (9.99 sec)

describe SELECT t_channel_id,login FROM test force index (t_channel_id) WHERE t_channel_id IS NOT NULL AND videos_scanned IS NULL AND videos_scanned_lock=0 limit 1;
+----+-------------+-------+------------+-------+---------------+--------------+---------+------+----------+----------+--------------------------+
| id | select_type | table | partitions | type  | possible_keys | key          | key_len | ref  | rows     | filtered | Extra                    |
+----+-------------+-------+------------+-------+---------------+--------------+---------+------+----------+----------+--------------------------+
|  1 | SIMPLE      | test  | NULL       | range | t_channel_id  | t_channel_id | 1023    | NULL | 16992061 |     0.02 | Using where; Using index |
+----+-------------+-------+------------+-------+---------------+--------------+---------+------+----------+----------+--------------------------+

explain format=json SELECT t_channel_id,login FROM test force index (t_channel_id) WHERE t_channel_id IS NOT NULL AND videos_scanned IS NULL AND videos_scanned_lock=0 limit 1;
{
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "4712106.82"
    },
    "table": {
      "table_name": "test",
      "access_type": "range",
      "possible_keys": [
        "t_channel_id"
      ],
      "key": "t_channel_id",
      "used_key_parts": [
        "t_channel_id"
      ],
      "key_length": "1023",
      "rows_examined_per_scan": 16992061,
      "rows_produced_per_join": 3906,
      "filtered": "0.02",
      "using_index": true,
      "cost_info": {
        "read_cost": "4711716.19",
        "eval_cost": "390.62",
        "prefix_cost": "4712106.82",
        "data_read_per_join": "11M"
      },
      "used_columns": [
        "t_channel_id",
        "login",
        "videos_scanned",
        "videos_scanned_lock"
      ],
      "attached_condition": "((`db`.`test`.`videos_scanned_lock` = 0) and (`db`.`test`.`t_channel_id` is not null) and (`db`.`test`.`videos_scanned` is null))"
    }
  }

                                               QUERY PLAN                                                                                        

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

GroupAggregate  (cost=21267.11..21286.98 rows=461 width=31) (actual time=1.711..1.712 rows=1 loops=1)
Group Key: *
\-\>  Sort  (cost=21267.11..21268.91 rows=719 width=35) (actual time=1.564..1.591 rows=719 loops=1)
Sort Key: *
Sort Method: quicksort  Memory: 69kB
\-\>  Nested Loop  (cost=70.03..21233.00 rows=719 width=35) (actual time=0.483..1.454 rows=719 loops=1)
\-\>  Index Scan using *  (cost=0.28..8.30 rows=1 width=27) (actual time=0.017..0.018 rows=1 loops=1)
Index Cond: *
\-\>  Bitmap Heap Scan on measurements m  (cost=69.75..21213.91 rows=719 width=32) (actual time=0.240..0.994 rows=719 loops=1)
Recheck Cond: *
Filter: *
Rows Removed by Filter: 5241
Heap Blocks: exact=50
\-\>  Bitmap Index Scan on * (cost=0.00..69.57 rows=6018 width=0) (actual time=0.224..0.224 rows=5960 loops=1)
Index Cond: *
Planning Time: 0.697 ms
**Execution Time: 1.766 ms**
(17 rows)

                                              QUERY PLAN                                                                                        

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

GroupAggregate  (cost=21267.11..21286.98 rows=461 width=31) (actual time=0.897..0.898 rows=1 loops=1)
Group Key: *
\-\>  Sort  (cost=21267.11..21268.91 rows=719 width=35) (actual time=0.795..0.831 rows=719 loops=1)
Sort Key: *
Sort Method: quicksort  Memory: 69kB
\-\>  Nested Loop  (cost=70.03..21233.00 rows=719 width=35) (actual time=0.178..0.718 rows=719 loops=1)
\-\>  Index Scan using * (cost=0.28..8.30 rows=1 width=27) (actual time=0.004..0.005 rows=1 loops=1)
Index Cond: *
\-\>  Bitmap Heap Scan on measurements m  (cost=69.75..21213.91 rows=719 width=32) (actual time=0.081..0.457 rows=719 loops=1)
Recheck Cond: *
Filter: *
Rows Removed by Filter: 5241
Heap Blocks: exact=50
\-\>  Bitmap Index Scan on * (cost=0.00..69.57 rows=6018 width=0) (actual time=0.073..0.073 rows=5960 loops=1)
Index Cond: * 
Planning Time: 0.336 ms
**Execution Time: 0.929 ms**
(17 rows)

                                              QUERY PLAN                                                                                        

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

GroupAggregate  (cost=21267.11..21286.98 rows=461 width=31) (actual time=0.873..0.873 rows=1 loops=1)
Group Key: *
\-\>  Sort  (cost=21267.11..21268.91 rows=719 width=35) (actual time=0.794..0.813 rows=719 loops=1)
Sort Key: *
Sort Method: quicksort  Memory: 69kB
\-\>  Nested Loop  (cost=70.03..21233.00 rows=719 width=35) (actual time=0.168..0.717 rows=719 loops=1)
\-\>  Index Scan using * (cost=0.28..8.30 rows=1 width=27) (actual time=0.004..0.004 rows=1 loops=1)
Index Cond: *
\-\>  Bitmap Heap Scan on measurements m  (cost=69.75..21213.91 rows=719 width=32) (actual time=0.071..0.457 rows=719 loops=1)
Recheck Cond: * 
Filter: *
Rows Removed by Filter: 5241
Heap Blocks: exact=50
\-\>  Bitmap Index Scan on * 
(cost=0.00..69.57 rows=6018 width=0) (actual time=0.063..0.063 rows=5960 loops=1)
Index Cond: *
Planning Time: 0.304 ms
**Execution Time: 0.903 ms**
(17 rows)

\---------------------------------------------------------------------------------------------------------------

Time (mean ± σ):      **98.1 ms** ±  28.1 ms    \[User: 30.7 ms, System: 11.1 ms\]Range (min … max):    75.6 ms … 129.5 ms    3 runs

\---------------------------------------------------------------------------------------------------------------  

Estou usando o hyperfine para avaliar o desempenho da minha consulta no PostgreSQL. Usei --runs 3a opção de executá-lo três vezes. Como você pode ver, o tempo de execução para todas as três vezes em que executo a consulta leva 1,766, 0,929 e 0,903 ms, respectivamente. Minha pergunta é: por que a média é = 98,1 ms? O que isso significa representa? Porque não faz sentido que o tempo de execução esteja entre 0,9 ms - 1,7 ms, enquanto a média deles é de 98,1 ms. Testei executar essa mesma consulta no Postico e demorou 0,903 ms. Só estou curioso para saber o que a média representa se não representa o tempo médio de execução.