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

David Fetter <david(at)fetter(dot)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(at)burri(dot)li
>> PostgreSQL version: 13.2
>> Operating system: Linux &amp; 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(at)[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