Chris Halcrow's questions

Estou usando o PgAdmin 4 v6 e, para alguns dados de timestamp com tipo de dados timestamp with time zone, estou vendo no PgAdmin assim:

2022-03-06 16:11:33+04

Por que o +04ser exibido?

Eu olhei para o seguinte guia postgres:

https://www.postgresql.org/docs/9.2/datatype-datetime.html#:~:text=PostgreSQL%20assumes%20your%20local%20time,being%20displayed%20to%20the%20client .

Afirma o seguinte:

Todas as datas e horas com reconhecimento de fuso horário são armazenadas internamente em UTC. Eles são convertidos para a hora local na zona especificada pelo parâmetro de configuração TimeZone antes de serem exibidos ao cliente.

A referência aqui afirma o seguinte sobre a configuração do TimeZone no Postgres:

TimeZone (string)Define o fuso horário para exibir e interpretar carimbos de hora. O padrão integrado é GMT, mas normalmente é substituído em postgresql.conf; O initdb instalará uma configuração correspondente ao ambiente do sistema.

Isso sugere que um fuso horário derivado de alguma forma do sistema host do banco de dados está sendo adicionado ao postgresql.conf.

Presumo que a razão pela qual vejo o deslocamento no PgAdmin é que o PgAdmin está exibindo uma versão convertida do valor armazenado, com base nas informações de fuso horário para o sistema host do banco de dados, que foi armazenado em postgresql.conf. Alguém pode confirmar se é isso que o PgAdmin faz quando exibe dados com tipo de dados timestamp with timezone?

Tenho a seguinte consulta no SQL server:

declare @timestamp_start date = getdate() - 1
declare @timestamp_end date = getdate()

SELECT  
    my_date = a.itemTimestamp
FROM
    my_table a with(nolock)
WHERE 
    (@timestamp_start is null OR a.itemTimestamp >= @timestamp_start)
    AND (@timestamp_end is null OR a.itemTimestamp < @timestamp_end)

É extremamente lento (90s para < 2000 registros), porque o plano de execução usa o índice clusterizado da coluna PK para 'my_table':

Por que isso está acontecendo e como posso otimizar o desempenho da consulta?

Digamos que temos 2 consultas completamente diferentes, que fazem referência a uma tabela temporária com o mesmo nome:

consulta um .... opera em: #tempTableName

consulta dois .... opera em: #tempTableName

Eu pesquisei isso e descobri que "#temp é uma tabela temporária local e, portanto, não é visível para outras conexões", no entanto, não tenho certeza do que uma conexão realmente significa em profundidade no contexto de consultas SQL. O SQL considera que há uma 'conexão' separada para cada consulta separada que é executada ou uma conexão é compartilhada de alguma forma?

Especificamente, minha pergunta é "o que está acontecendo se as duas consultas no meu cenário estão sendo acessadas pelo mesmo login", por exemplo, vários aplicativos .NET estão usando a mesma cadeia de conexão .NET e acessando simultaneamente o banco de dados. Eles vão acessar potencialmente a mesma tabela temporária se ambas as consultas no meu cenário estiverem sendo executadas simultaneamente? E as fechaduras? Preciso fazer alguma coisa para evitar o acesso indesejado durante as operações na mesa?

Eu olhei para esta resposta, https://stackoverflow.com/questions/466947/are-temporary-tables-thread-safe , no entanto, eu realmente preciso de algo como uma explicação 'fingir que tenho 6 anos' para que eu Estou muito claro sobre o que está acontecendo no meu cenário hipotético em termos de exatamente como as consultas SQL estão utilizando conexões e determinando acesso exclusivo etc. Quaisquer diagramas ou ponteiros para recursos que possam me dar um comando completo disso seria ótimo!