All perguntas(dba)

Estamos realizando Citusbenchmarking e nos deparamos com uma situação onde o planejador faz o parallel execution planmas durante a execução não parallel workerssão lançados. O cluster possui 3 nós de trabalho, cada um com 2CPUs em execução no Centos. Qual pode ser a razão por trás disso?

->  Finalize Aggregate  (cost=76650.31..76650.32 rows=1 width=32) (actual time=174741.832..174741.999 rows=1 loops=1)
                 ->  Gather  (cost=76650.09..76650.30 rows=2 width=32) (actual time=174741.807..174741.974 rows=1 loops=1)
                       Workers Planned: 2
                       Workers Launched: 0
                       ->  Partial Aggregate  (cost=75650.09..75650.10 rows=1 width=32) (actual time=174740.490..174740.492 rows=1 loops=

A consulta que estamos usando para benchmarking é

select sum(amount) from tab_dist_1 where id>=49820 and id<=59743292;

Durante a instalação do MongoDB Community 7.0, o instalador solicita os caminhos para o banco de dados e eu os aponto para a unidade E: dedicada de 50 GB vazia, que foi criada especialmente para o MongoDB.

A próxima etapa indica que a unidade de destino C: não tem espaço suficiente. E a lista de unidades abaixo mostra C: e E:, mas E: não pode ser selecionado.

O MongoDB não pode ser instalado em nenhuma unidade diferente de C:?

Eu tenho uma tabela com 1b linhas e ela continua crescendo. Atualmente, uso o pg_partman para particionamento por mês. Existem muitas consultas selecionadas apenas para os meses atuais ou anteriores. É possível mover partições "antigas" para outro servidor? Então, idealmente, quero ter 1 servidor (poderoso com discos rápidos) apenas com partições recentes e um segundo servidor (barato) com outras partições. Devo usar a extensão postgres_fdw para vincular partições? Quais são as boas práticas para alcançar este tipo de esquema?

Tenho um banco de dados SQL Server com uma tabela com um gatilho que é executado após a inserção. Se eu inserir duas entradas diretamente, uma após a outra, é importante que a segunda entrada seja inserida somente após o término da execução do gatilho. Posso confiar nisso? Ou posso ter uma condição de corrida problemática em algum momento?

O código do gatilho fica assim:

ALTER TRIGGER [dbo].[TR_MachineState_Desable_OldData_ON_Insert]
   ON [dbo].[machine_state]
   AFTER INSERT
AS 
BEGIN
      DECLARE @RowID INT;
      DECLARE @Name NVARCHAR(30);
      DECLARE @MachineState NVARCHAR(30);
      DECLARE @Devicescount INT;
      DECLARE @StartedOn DATETIME;
      DECLARE @CreateOn DATETIME;
      DECLARE @ToolName NVarchar(30);


    -- SET NOCOUNT ON added to prevent extra result sets from
    -- interfering with SELECT statements.
    SET NOCOUNT ON;

    -- Insert statements for trigger here
          SELECT
                   @RowID=[RowId]
                  ,@Name= [Name]
                  ,@MachineState=[MachineState]
                  ,@Devicescount=[Devicescount]
                  ,@StartedOn= [StartedOn]
                  ,@CreateOn =[ActionDate]
                  ,@ToolName=[ToolName]
        from inserted ;

    update [machine_state]
    set [IsActive]=0
    where  [Name] =@Name and  ToolName = @ToolName and  RowId <> @RowID

    update machine_state
    set IsActive =1
    where RowId=@RowID


END

Como você pode ver, o gatilho garante que apenas a última entrada com o mesmo nome de ferramenta e o mesmo nome seja IsActiveverdadeira.

A página de documentação DBMS_ADVANCED_REWRITE para Oracle explica como declarar reescritas de consulta e eliminá-las, mas não explica como você pode listar todas as reescritas declaradas no banco de dados.

É possível listar todas as reescritas declaradas?

Sou um usuário regular do SQL-Server Management Studio mas agora estou com uma situação totalmente estranha: quando pressiono F5ou clico em "Executar", o SQL-Server Management Studio não executa minha consulta. Em vez disso, abre a caixa de diálogo "Salvar resultados", como você pode ver:

Alguém já viu isso e sabe como lidar com isso?
desde já, obrigado

Criei 2 tabelas idênticas particionadas por uma coluna inteira. Em uma das tabelas a coluna é computada, na outra tabela a coluna não é computada.

Quando eu consulto a tabela com coluna computada filtrando uma única classificação de partição com índice clusterizado (assumindo que os dados de saída já estão classificados, portanto, nenhuma classificação adicional é necessária), ela verifica a tabela inteira.

CREATE PARTITION FUNCTION pf_test(int) AS RANGE RIGHT FOR VALUES(1, 2, 3, 4)
GO
CREATE PARTITION SCHEME ps_test AS PARTITION pf_test ALL TO([PRIMARY])
GO
CREATE TABLE test_computed
(
    ID BIGINT NOT NULL, 
    ID_C AS CAST(ID % 4 AS INT) PERSISTED, 
    PRIMARY KEY CLUSTERED (ID, ID_C) ON ps_test(ID_C)
) ON ps_test(ID_C)
GO
    
CREATE TABLE test_not_computed
(
    ID BIGINT NOT NULL, 
    ID_C INT NOT NULL, 
    PRIMARY KEY CLUSTERED (ID, ID_C) ON ps_test(ID_C)
) ON ps_test(ID_C)
GO
    
INSERT INTO test_computed(ID)
SELECT TOP 1000000 ROW_NUMBER() OVER(ORDER BY GETDATE())
FROM sys.all_columns a
CROSS JOIN sys.all_columns b
GO
    
INSERT INTO test_not_computed(ID, ID_C)
SELECT TOP 1000000 
    ROW_NUMBER() OVER(ORDER BY GETDATE()), 
    ROW_NUMBER() OVER(ORDER BY GETDATE()) % 4
FROM sys.all_columns a
CROSS JOIN sys.all_columns b
GO

Os dados são idênticos, mas os planos de execução para cada consulta são diferentes.

SELECT TOP 100 *
FROM test_computed
WHERE $partition.pf_test(ID_C) = 1
ORDER BY ID DESC
    
SELECT TOP 100 *
FROM test_not_computed
WHERE $partition.pf_test(ID_C) = 1
ORDER BY ID desc

A tabela real possui bilhões de linhas; estamos usando particionamento para evitar a varredura de toda a tabela.

A versão do SQL Server é

Microsoft SQL Server 2019 (RTM-CU26) (KB5035123) - 15.0.4365.2 (X64)
29 de março de 2024 23:02:47 Copyright (C) 2019 Microsoft Corporation
Developer Edition (64 bits) no Windows Server 2022 Standard 10.0 (Build 20348 :)

Minha tabela Postgres possui uma coluna de intervalo contendo carimbos de data e hora com fuso horário. Eu criei um índice no limite inferior do intervalo, assim:

CREATE INDEX bdg_sys_period_start_idx ON building USING btree (lower(sys_period));

Agora estou tentando executar a seguinte consulta:

select * from building where lower(sys_period) > '2024-05-12 10:31:14.481545+01'::timestamptz;

Aí vem a parte interessante. Eu executo um ANALYZE na tabela e depois um EXPLAIN na consulta. Eu entendi isso:

Perfeito, o Postgres quer usar meu novo índice!

Então eu inicio a consulta e leva muito tempo. Paro a consulta e executo EXPLAIN novamente. E, surpresa, o planejador de consultas agora me diz que deseja usar uma varredura sequencial.

Vejo que o número planejado de linhas retornadas salta de 97 mil para 1,6 milhões. O número real é 30 linhas.

Tenho muitas perguntas sobre esta situação:

• Por que o planejador de consultas mudou repentinamente de ideia?
• As estatísticas devem ser coletadas para colunas de intervalo? Eu vi essa discussão , mas não tenho certeza se isso foi implementado.
• Tentei criar uma estatística personalizada em lower(sys_period) diretamente:

CREATE STATISTICS IF NOT EXISTS sys_period_start_range ON ( lower(sys_period) ) FROM building;

É suposto ser útil?

• Tentei aumentar o tamanho da estatística na coluna sys_period

ALTER TABLE building ALTER sys_period SET STATISTICS 1000;

É suposto ser útil?

Agradeço antecipadamente por sua ajuda.

Planejando algumas tabelas novas, estou tentando decidir se um índice deve ser "crescente" ou "descendente".

A tabela será bem grande (imagino aproximadamente 2.000 inserções por minuto, migrando inicialmente de uma tabela diferente com cerca de 1 bilhão de linhas).

Usarei a extensão timescaledb para isso (para particionamento por tempo).

É assim que a tabela pode ser criada:

create table "Sample"(
    "id" bigserial,
    "deviceId" int not null,
    "timestamp" timestamptz not null,
    "value" float8 not null
);
select create_hypertable('"Sample"', 'timestamp'); -- creates a desc index on "timestamp"

create index on "Sample"("deviceId", "timestamp"); -- should this be "desc"?

Estas são as duas consultas mais comuns que executaremos (deviceId e timestamps podem variar, é claro):

select "timestamp", "value"
from "Sample" where "deviceId"=123 and "timestamp"<'2024-01-01Z'
order by "timestamp" desc limit 1;

E

select "timestamp", "value"
from "Sample" where "deviceId"=123 and "timestamp" between '2024-01-01Z' and '2024-02-01Z'
order by "timestamp" asc;

Então, o que estou tentando entender é em que ordem o "carimbo de data e hora" deve estar? E porque?

Minha intuição (provavelmente errada) me diz que o índice com "timestamp" deveria estar em ordem crescente, pois preciso ordenar os dados por timestamp em ordem crescente .

Porém, os exemplos na documentação da escala de tempo sempre indexam as colunas de tempo em ordem decrescente. Eu não entendo muito bem o porquê.

Qual é a escolha ideal de índices aqui?

Vejo consultas em execução como FETCH ALL IN "<unnamed portal 847>"

Como posso descobrir qual consulta está anexada a este cursor?