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
