Thread: Problem with indices from 10 to 13

Daniel Diniz Desenvolvimento Cel.: 11981464923 www.flashcourier.com.br       #SomosTodosFlash #GrupoMOVE3

"Esta mensagem e seus anexos são dirigidos exclusivamente para os seus destinatários, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, não deve revelar, copiar, distribuir ou de qualquer forma utilizá-la. A empresa não se responsabiliza por alterações no conteúdo desta mensagem depois do seu envio."

Daniel Diniz <daniel@flashcourier.com.br> writes:
> Hello I migrated from postgres 10 to 13 and I noticed that there was a big increase in a querie that I use, I did
explainin 10 and 13 and the difference is absurd, the indices and data are the same in 2. I've re-created and
re-indexedbut I don't know what changed from 10 to 13 which made the performance so bad, I don't know if it needs some
extraparameter in some conf on 13. 

This complaint is missing an awful lot of supporting information.

> "                                ->  Bitmap Heap Scan on hawbs h  (cost=1058.34..26261.32 rows=21451 width=46)
(actualtime=201.956..201.966 rows=4 loops=1)" 
> "                                      Recheck Cond: ((nome_des)::text ~~*
convert_from('\x255354455048414e592053544f4557204c45414e44524f25'::bytea,'LATIN1'::name))" 
> "                                      Filter: (tipo_hawb_id = ANY ('{1,10,3}'::integer[]))"
> "                                      Heap Blocks: exact=4"
> "                                      ->  Bitmap Index Scan on idx_nome_des  (cost=0.00..1052.98 rows=22623 width=0)
(actualtime=201.942..201.943 rows=4 loops=1)" 
> "                                            Index Cond: ((nome_des)::text ~~*
convert_from('\x255354455048414e592053544f4557204c45414e44524f25'::bytea,'LATIN1'::name))" 

For starters, how in the world did you get that query condition out of

> where h.nome_des ilike '%STEPHANY STOEW LEANDRO%'

?  What data type is h.nome_des, anyway?  And what kind of index
is that --- it couldn't be a plain btree, because we wouldn't consider
~~* to be indexable by a btree.

However, the long and the short of it is that this rowcount estimate
is off by nearly four orders of magnitude (21451 estimated vs. 4
actual is pretty awful).  It's probably just luck that you got an
acceptable plan out of v10, and bad luck that you didn't get one
out of v13 --- v13's estimate is not better, but it's not much
worse either.  You need to do something about improving that
estimate if you'd like reliable query planning.  Since I'm not
too sure which operator you're actually invoking, it's hard to
offer good advice about how hard that might be.

            regards, tom lane

Daniel Diniz Desenvolvimento Cel.: 11981464923 www.flashcourier.com.br       #SomosTodosFlash #GrupoMOVE3

"Esta mensagem e seus anexos são dirigidos exclusivamente para os seus destinatários, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, não deve revelar, copiar, distribuir ou de qualquer forma utilizá-la. A empresa não se responsabiliza por alterações no conteúdo desta mensagem depois do seu envio."

Daniel Diniz Desenvolvimento Cel.: 11981464923 www.flashcourier.com.br       #SomosTodosFlash #GrupoMOVE3

"Esta mensagem e seus anexos são dirigidos exclusivamente para os seus destinatários, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, não deve revelar, copiar, distribuir ou de qualquer forma utilizá-la. A empresa não se responsabiliza por alterações no conteúdo desta mensagem depois do seu envio."

Hello I migrated from postgres 10 to 13 and I noticed that there was a big increase in a querie that I use, I did explain in 10 and 13 and the difference is absurd, the indices and data are the same in 2. I've re-created and re-indexed but I don't know what changed from 10 to 13 which made the performance so bad, I don't know if it needs some extra parameter in some conf on 13.

Postgres 13

"QUERY PLAN"

"Limit  (cost=1.13..26855.48 rows=30 width=137) (actual time=10886.585..429803.463 rows=4 loops=1)"

"  ->  Nested Loop  (cost=1.13..19531164.71 rows=21819 width=137) (actual time=10886.584..429803.457 rows=4 loops=1)"

"        Join Filter: (h.ult_eve_id = ev.evento_id)"

"        Rows Removed by Join Filter: 252"

"        ->  Nested Loop  (cost=1.13..19457514.32 rows=21819 width=62) (actual time=10886.326..429803.027 rows=4 loops=1)"

"              ->  Nested Loop  (cost=0.85..19450780.70 rows=21819 width=55) (actual time=10886.259..429802.908 rows=4 loops=1)"

"                    ->  Index Scan Backward using hawbs_pkey on hawbs h  (cost=0.57..19444209.67 rows=21819 width=46) (actual time=10886.119..429802.676 rows=4 loops=1)"

"                          Filter: ((tipo_hawb_id = ANY ('{1,10,3}'::integer[])) AND ((nome_des)::text ~~* convert_from('\x255354455048414e592053544f4557204c45414e44524f25'::bytea, 'LATIN1'::name)))"

"                          Rows Removed by Filter: 239188096"

Index Scan Backward looks suspicious to me.

239,188,096  rows removed by filter it's a lot of work.

Do you, run analyze?

Daniel Diniz <daniel@flashcourier.com.br> writes:
> The index I use is the GIN.

pg_trgm, you mean?  That answers one question, but you still didn't
explain what type h.nome_des is, nor how bytea and convert_from()
are getting into the picture.

The second part of that is probably not critical, since the planner
should be willing to reduce the convert_from() call to a constant
for planning purposes, so I'm unclear as to why the estimate for
the ilike clause is so bad.  Have you tried increasing the statistics
target for h.nome_des to see if the estimate gets better?

            regards, tom lane

Daniel Diniz Desenvolvimento Cel.: 11981464923 www.flashcourier.com.br       #SomosTodosFlash #GrupoMOVE3

"Esta mensagem e seus anexos são dirigidos exclusivamente para os seus destinatários, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, não deve revelar, copiar, distribuir ou de qualquer forma utilizá-la. A empresa não se responsabiliza por alterações no conteúdo desta mensagem depois do seu envio."

On Wed, Sep 29, 2021 at 02:11:15AM +0000, Daniel Diniz wrote:
> How do i increase  the statistics target for h.nome_des?
> And why uploading the dump at 10 and at 13 is there this difference?

It's like ALTER TABLE h ALTER nome_des SET STATISTICS 2000; ANALYZE h;
https://www.postgresql.org/docs/current/sql-altertable.html

-- 
Justin

Daniel Diniz Desenvolvimento Cel.: 11981464923 www.flashcourier.com.br       #SomosTodosFlash #GrupoMOVE3

"Esta mensagem e seus anexos são dirigidos exclusivamente para os seus destinatários, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, não deve revelar, copiar, distribuir ou de qualquer forma utilizá-la. A empresa não se responsabiliza por alterações no conteúdo desta mensagem depois do seu envio."