pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feed From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: David Steele <david@pgmasters.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Haribabu Kommi <kommi.haribabu@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means
Date: Tue, 20 Mar 2018 21:14:04 +0100
Message-ID: <3b3d8eac-c709-0d25-088e-b98339a1b28a@2ndquadrant.com> (raw )
In-Reply-To: <8b29edcb-cbc0-5414-996f-520f75b94d3b@2ndquadrant.com >
References: <16db4468-edfa-830a-f921-39a50498e77e@2ndquadrant.com >
<19990.1500936945@sss.pgh.pa.us >
<3d250597-384e-c5f4-7533-b513e366888f@2ndquadrant.com >
<CAJrrPGeQcsBXhuJA1vQ25PS0wAqfo0v_mXtwmt4VcOmxKSvfCA@mail.gmail.com >
<94f58897-861b-accf-a9f1-af4be816c0d3@2ndquadrant.com >
<CAJrrPGfTQ3w=5BdprWgQghuM7ujtBy2Sthr6zRwY0QeRBQd2RQ@mail.gmail.com >
<13097.1509650125@sss.pgh.pa.us >
<3dca6a76-fa4b-66ab-c0db-496335d650b1@2ndquadrant.com >
<CAB7nPqS4VSUiaFnGmR2k95-RtEi++SEwZk32pMu_31VLyMpK0Q@mail.gmail.com >
<20180105042528.GK2416@tamriel.snowman.net >
<1e831867-c46c-8f21-79d4-5de70cac5822@2ndquadrant.com >
<13711.1515440364@sss.pgh.pa.us >
<01387f5d-a95b-d159-becb-cf9ff9ba4e41@2ndquadrant.com >
<db11d513-4af4-0d1b-514b-16617385f068@pgmasters.net >
<8b29edcb-cbc0-5414-996f-520f75b94d3b@2ndquadrant.com >
Hi,
So here is an updated version of the patch/fix, addressing the remaining
issues in v3 posted by Tom in November.
The 0001 part is actually a bugfix in bloom and spgist index AM, which
did something like this:
reltuples = IndexBuildHeapScan(...)
result->heap_tuples = result->index_tuples = reltuples;
That is, these two AMs simply used the number of heap rows for the
index. That does not work for partial indexes, of course, where the
correct index reltuples value is likely much lower.
0001 fixes this by tracking the number of actually indexed rows in the
build states, just like in the other index AMs.
A VACUUM or ANALYZE will fix the estimate, of course, but for tables
that are not changing very much it may take quite a while. So I think
this is something we definitely need to back-patch.
The 0002 part is the main part, unifying the definition of reltuples on
three main places:
a) acquire_sample_rows (ANALYZE)
b) lazy_scan_heap (VACUUM)
c) IndexBuildHeapRangeScan (CREATE INDEX)
As the ANALYZE case seems the most constrained, the other two places
were updated to use the same criteria for which rows to include in the
reltuples estimate:
* HEAPTUPLE_LIVE
* HEAPTUPLE_INSERT_IN_PROGRESS (same transaction)
* HEAPTUPLE_DELETE_IN_PROGRESS (not the same trasaction)
This resolves the issue with oscillating reltuples estimates, produced
by VACUUM and ANALYZE (with many non-removable dead tuples).
I've checked all IndexBuildHeapRangeScan callers, and none of them is
using the reltuples estimate for anything except for passing it to
index_update_stats. Aside from the bug fixed in 0001, of course.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-Compute-index_tuples-correctly-in-bloom-and-spgist.patch.gz (application/gzip, 1.4K) download
0002-Unify-the-definition-of-reltuples-in-VACUUM-ANALYZE-.patch.gz (application/gzip, 4.6K) download
view thread (26+ messages) latest in thread
Message-ID: <3b3d8eac-c709-0d25-088e-b98339a1b28a@2ndquadrant.com>
Permalink: ../3b3d8eac-c709-0d25-088e-b98339a1b28a@2ndquadrant.com/
Also on: postgresql.org/message-id/3b3d8eac-c709-0d25-088e-b98339a1b28a@2ndquadrant.com
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@2ndquadrant.com, david@pgmasters.net, tgl@sss.pgh.pa.us, sfrost@snowman.net, michael.paquier@gmail.com, kommi.haribabu@gmail.com
Subject: Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means
In-Reply-To: <3b3d8eac-c709-0d25-088e-b98339a1b28a@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox