| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Nikita Malakhov <hukutoc(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Unstable path in index regress test query |
| Date: | 2026-01-23 18:11:19 |
| Message-ID: | 3123188.1769191879@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Nikita Malakhov <hukutoc(at)gmail(dot)com> writes:
> While doing some tests I've stumbled upon an unstable behavior of the query
> explain
> SELECT unique1 FROM tenk1
> WHERE unique1 IN (1,42,7)
> ORDER BY unique1;
> from create_index regress test.
I wouldn't call what you're showing here an instability.
You create and populate the table, but your test script
isn't giving autovacuum any time to catch up, so the
first EXPLAIN is based on default behaviors without stats.
Then when you do an ANALYZE, the plan changes because the
rowcount estimates change.
You probably should make that a VACUUM ANALYZE, actually,
to ensure that the whole table is marked all-visible.
That can affect the estimated cost of an index-only scan too.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nikita Malakhov | 2026-01-23 18:17:38 | Re: Unstable path in index regress test query |
| Previous Message | Nikita Malakhov | 2026-01-23 18:00:11 | Unstable path in index regress test query |