From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | James Coleman <jtc331(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Analyze on table creation? |
Date: | 2023-06-26 20:00:23 |
Message-ID: | 20230626200023.fpu2jeb3qcst4n73@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-06-26 13:40:49 -0400, James Coleman wrote:
> Have we ever discussed running an analyze immediately after creating a table?
That doesn't make a whole lot of sense to me - we could just insert the
constants stats we wanted in that case.
> Consider the following:
>
> create table stats(i int, t text not null);
> explain select * from stats;
> Seq Scan on stats (cost=0.00..22.70 rows=1270 width=36
> analyze stats;
> explain select * from stats;
> Seq Scan on stats (cost=0.00..0.00 rows=1 width=36)
>
> Combined with rapidly increasing error margin on row estimates when
> adding joins means that a query joining to a bunch of empty tables
> when a database first starts up can result in some pretty wild plan
> costs.
The issue is that the table stats are likely going to quickly out of date in
that case, even a hand full of inserts (which wouldn't trigger
autovacuum analyzing) would lead to the "0 rows" stats causing very bad plans.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Mikhail Gribkov | 2023-06-26 20:10:00 | Re: Fixing tab-complete for dollar-names |
Previous Message | Andres Freund | 2023-06-26 19:54:44 | Detecting use-after-free bugs using gcc's malloc() attribute |