Martin Brown's questions

Estou portando um aplicativo do SQL Server para o PostgreSQL. A maior parte disso é simples, pois o aplicativo só faz seleções, inserções e atualizações simples. Porém preciso criar um usuário para acessar o banco de dados. O código do SQL Server cria seu usuário assim:

USE [master] CREATE LOGIN [ExampleUserName] WITH PASSWORD = 'ExamplePassword', CHECK_EXPIRATION=OFF, CHECK_POLICY=ON;
USE [ExampleDB];
CREATE USER [ExampleUserName] FOR LOGIN [ExampleUserName];
ALTER ROLE [db_datawriter] ADD MEMBER [ExampleUserName];
ALTER ROLE [db_datareader] ADD MEMBER [ExampleUserName];

Qual é o equivalente disso no PostgreSQL?

Se eu tiver uma UPDATEdeclaração que na verdade não altera nenhum dado (porque os dados já estão no estado atualizado). Existe algum benefício de desempenho em colocar uma verificação na WHEREcláusula para evitar a atualização?

Por exemplo, haveria alguma diferença na velocidade de execução entre UPDATE 1 e UPDATE 2 no seguinte:

CREATE TABLE MyTable (ID int PRIMARY KEY, Value int);
INSERT INTO MyTable (ID, Value)
VALUES
    (1, 1),
    (2, 2),
    (3, 3);

-- UPDATE 1
UPDATE MyTable
SET
    Value = 2
WHERE
    ID = 2
    AND Value <> 2;
SELECT @@ROWCOUNT;

-- UPDATE 2
UPDATE MyTable
SET
    Value = 2
WHERE
    ID = 2;
SELECT @@ROWCOUNT;

DROP TABLE MyTable;

O motivo pelo qual pergunto é que preciso que a contagem de linhas inclua a linha inalterada para saber se devo fazer uma inserção se o ID não existir. Como tal, usei o formulário UPDATE 2. Se houver um benefício de desempenho ao usar o formulário UPDATE 1, é possível obter a contagem de linhas que preciso de alguma forma?

É possível obter uma lista de procedimentos armazenados criados com WITH EXECUTE?

Tentei olhar para sys.procedures, mas todos eles têm o principal definido como null, e sei que existem alguns procedimentos criados dessa maneira.

Provavelmente não estou entendendo alguma coisa, mas aqui está a pergunta.

Fiz uma consulta em dm_db_index_usage_stats. Percebi que alguns dos meus índices têm números grandes (6,5 milhões e 20 mil) na coluna user_lookups, mas também têm um zero nas colunas user_seeks e user_scans.

Meu entendimento (de livros on-line ) é que a coluna user_lookups conta pesquisas de favoritos. Pelo que entendi, é quando o banco de dados não consegue encontrar todas as colunas necessárias em um índice e precisa visitar a tabela principal ou o índice clusterizado para as colunas restantes. No entanto, por que o servidor SQL faria isso se nunca tivesse feito uma busca ou varredura no índice?

Eu tenho dois procedimentos armazenados que estão travando quando o sistema está sob carga. O Proc A está selecionando em uma tabela enquanto o Proc B está inserindo na mesma tabela. O gráfico de bloqueio está mostrando que o Proc A tem um bloqueio de página no modo S para o qual o Proc B deseja um bloqueio no modo IX, no entanto, o Proc A está aguardando um bloqueio de página no modo S para uma página diferente em que o Proc B já possui um bloqueio de página no modo IX .

Claramente, isso pode ser resolvido garantindo que ambas as consultas bloqueiem as páginas na tabela na mesma ordem, mas não consigo descobrir como fazer isso.

Minha pergunta é: como o SQL Server determina em que ordem bloquear as páginas ao fazer INSERTs e SELECTs e como você pode modificar esse comportamento?