Re: BUG #16967: Extremely slow update statement in trigger

David Fetter <david@fetter.org> writes:
> On Fri, Apr 16, 2021 at 04:52:15PM +0000, PG Bug reporting form wrote:
>> Bug reference:      16967
>> Logged by:          Nicolas Burri
>> Email address:      postgres@burri.li
>> PostgreSQL version: 13.2
>> Operating system:   Linux & Windows
>> ...

> I'm including what I found on dropbox below. In future, please include
> the entire content in emails so it stays independent of sites that
> might not still be there when people look back.

Thanks for putting that into the archives.

> I did find something interesting here's the EXPLAIN for the update
> that's intended to change everything in the table. Note that the
> estimated rows is 1:
>     shackle@[local]:5414/slow_stmt_triggers(14devel)(110490) # explain update demo set type = 'black' where
type='blue';
>                               QUERY PLAN
>     ══════════════════════════════════════════════════════════════
>      Update on demo  (cost=0.00..3976.35 rows=0 width=0)
>        ->  Seq Scan on demo  (cost=0.00..3976.35 rows=1 width=34)
>              Filter: ((type)::text = 'blue'::text)
>     (3 rows)

Yeah.  Of course, the plan for the UPDATE itself looks just the
same post-ANALYZE.  What we can infer is that the complex query
within the trigger function got a really stupid plan when there
were no stats, and then a better plan once there were some.

> tl;dr: running ANALYZE after a bulk load is a good idea, and I don't
> see a bug here.

Agreed, there's little evidence here of anything but the known
issue that auto-ANALYZE doesn't act instantaneously.  If we had
an easy way to make that better, we would, but ...

            regards, tom lane