mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-12 15:03:25 +02:00
5843659d09
Buildfarm members ayu and tern have sometimes shown a different plan than expected for this query. I'd been unable to reproduce that before today, but I finally realized what is happening. If there is a concurrent open transaction (probably an autovacuum run in the buildfarm, but this can also be arranged manually), then the index entries for the rows removed by the DELETE a few lines up are not killed promptly, causing a change in the planner's estimate of the extremal value of ft2.c1, which moves the rowcount estimate for "c1 > 1100" by enough to change the join plan from nestloop to hash. To fix, change the query condition to "c1 > 1000", causing the hash plan to be preferred whether or not a concurrent open transaction exists. Since this UPDATE is tailored to be a no-op, nothing else changes. Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=ayu&dt=2021-06-09%2022%3A45%3A48 Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=ayu&dt=2021-06-13%2022%3A38%3A18 Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tern&dt=2021-06-20%2004%3A55%3A36 |
||
|---|---|---|
| .. | ||
| expected | ||
| sql | ||
| .gitignore | ||
| connection.c | ||
| deparse.c | ||
| Makefile | ||
| option.c | ||
| postgres_fdw--1.0--1.1.sql | ||
| postgres_fdw--1.0.sql | ||
| postgres_fdw.c | ||
| postgres_fdw.control | ||
| postgres_fdw.h | ||
| shippable.c | ||