{"id":2463,"date":"2026-07-14T19:26:10","date_gmt":"2026-07-14T19:26:10","guid":{"rendered":"https:\/\/www.tiagoneves.net\/blog\/?p=2463"},"modified":"2026-07-14T19:26:13","modified_gmt":"2026-07-14T19:26:13","slug":"conversao-implicita-no-postgresql-por-que-o-comportamento-e-diferente-do-sql-server-e-onde-a-performance-realmente-morre","status":"publish","type":"post","link":"https:\/\/www.tiagoneves.net\/blog\/conversao-implicita-no-postgresql-por-que-o-comportamento-e-diferente-do-sql-server-e-onde-a-performance-realmente-morre\/","title":{"rendered":"Convers\u00e3o impl\u00edcita no PostgreSQL: por que o comportamento \u00e9 diferente do SQL Server (e onde a performance realmente morre)"},"content":{"rendered":"\n

Uma novidade antes de come\u00e7ar<\/mark><\/h2>\n\n\n\n

Se voc\u00ea acompanha o blog h\u00e1 algum tempo, j\u00e1 percebeu que praticamente tudo por aqui gira em torno de SQL Server. E faz sentido s\u00e3o mais de 15 anos vivendo esse banco em produ\u00e7\u00e3o, entre troubleshooting, corrup\u00e7\u00f5es de banco, migra\u00e7\u00f5es, tuning e muita madrugada de plant\u00e3o.<\/p>\n\n\n\n

Mas o mercado de dados mudou, e o PostgreSQL deixou de ser “o outro banco<\/strong>” para se tornar presen\u00e7a obrigat\u00f3ria na vida de qualquer DBA, est\u00e1 nas nuvens (RDS, Azure Database, Cloud SQL), nas startups, nas migra\u00e7\u00f5es de redu\u00e7\u00e3o de custo de licenciamento e cada vez mais, nas grandes empresas.<\/p>\n\n\n\n

H\u00e1 alguns meses venho estudando PostgreSQL a fundo, com foco de administra\u00e7\u00e3o e performance montando laborat\u00f3rio, quebrando, corrigindo e documentando.<\/p>\n\n\n\n

Ent\u00e3o, a partir deste post, o blog tamb\u00e9m ter\u00e1 conte\u00fado de PostgreSQL<\/strong>. E vou fazer do jeito que gostaria que tivessem feito comigo quando comecei, explicando cada comando novo que aparecer e sempre que poss\u00edvel, comparando com o equivalente no SQL Server<\/strong> porque aprender um banco novo fica muito mais f\u00e1cil quando voc\u00ea ancora no que j\u00e1 conhece. Ent\u00e3o se voc\u00ea \u00e9 DBA SQL Server curioso sobre o mundo Postgres, este blog agora tamb\u00e9m \u00e9 pra voc\u00ea.<\/p>\n\n\n\n

E nada melhor para estrear do que dar sequ\u00eancia a um assunto que j\u00e1 conhecemos bem por aqui.<\/p>\n\n\n\n

O problema<\/mark><\/h2>\n\n\n\n

No post <\/a>anterior<\/a>, vimos como no SQL Server uma tipagem errada o cl\u00e1ssico VARCHAR<\/code> vs NVARCHAR<\/code> gera convers\u00f5es impl\u00edcitas silenciosas que transformam Index Seeks em Index Scans. A pergunta natural de quem trabalha com os dois bancos \u00e9: e no PostgreSQL, isso acontece igual?<\/strong><\/p>\n\n\n\n

A resposta curta e grossa (=D) n\u00e3o igual mas acontece, e em lugares diferentes dos que voc\u00ea espera.<\/strong><\/p>\n\n\n\n

O sistema de tipos do PostgreSQL \u00e9 mais r\u00edgido que do SQL Server, onde o SQL Server tenta “adivinhar” e ajustar convertendo em segundo plano, o PostgresSQL muitas vezes simplesmente recusa a query com erro e isso \u00e9 uma prote\u00e7\u00e3o. Mas quando a convers\u00e3o impl\u00edcita passa<\/em> e cai na coluna e a\u00ed o \u00edndice B-Tree morre do mesmo jeito.<\/p>\n\n\n\n

Neste post vou mostrar, com EXPLAIN ANALYZE<\/code> real em um PostgreSQL 18, onde o \u00edndice sobrevive, onde ele morre, e um recurso do Postgres que o SQL Server n\u00e3o tem para resolver o problema.<\/p>\n\n\n\n

Montando o ambiente de teste<\/mark><\/h2>\n\n\n\n

Um detalhe did\u00e1tico importante, n\u00e3o adianta testar isso com meia d\u00fazia de linhas.<\/strong> Com uma tabela de 4 registros, o planner escolhe Seq Scan sempre, porque a tabela inteira cabe em uma p\u00e1gina e voc\u00ea vai concluir errado. Vamos popular com pelo menos 100 mil linhas com generate_series<\/code>.<\/p>\n\n\n\n

CREATE TABLE clientes (\n    id SERIAL PRIMARY KEY,\n    codigo_cliente VARCHAR(20) NOT NULL,\n    nome VARCHAR(100) NOT NULL,\n    criado_em TIMESTAMP NOT NULL DEFAULT now()\n);\n\nINSERT INTO clientes (codigo_cliente, nome, criado_em)\nSELECT 'C' || LPAD(g::text, 6, '0'),\n       'Cliente ' || g,\n       now() - (g || ' minutes')::interval\nFROM generate_series(1, 100000) g;\n\nCREATE INDEX idx_clientes_codigo ON clientes(codigo_cliente);\nCREATE INDEX idx_clientes_criado_em ON clientes(criado_em);\n\nANALYZE clientes;<\/code><\/pre>\n\n\n\n
Traduzindo para “SQL Server\u00eas”:<\/mark><\/strong><\/p>\n\n\n\n