From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.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: Sat, 18 Nov 2017 16:56:33 -0500
Message-ID: <27720.1511042193@sss.pgh.pa.us> (raw)
In-Reply-To: <3dca6a76-fa4b-66ab-c0db-496335d650b1@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>
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On 11/02/2017 08:15 PM, Tom Lane wrote:
>> However, I'm not sure we're there yet, because there remains a fairly
>> nasty discrepancy even once we've gotten everyone onto the same page
>> about reltuples counting just live tuples: VACUUM and ANALYZE have
>> different definitions of what's "live". In particular they do not treat
>> INSERT_IN_PROGRESS and DELETE_IN_PROGRESS tuples the same. Should we
>> try to do something about that? If so, what? It looks like ANALYZE's
>> behavior is pretty tightly constrained, judging by the comments in
>> acquire_sample_rows.
> ISTM we need to unify those definitions, probably so that VACUUM adopts
> what acquire_sample_rows does. I mean, if ANALYZE assumes that the stats
> will be updated at the end of transaction, why shouldn't VACUUM do the
> same thing?
That was the way I was leaning. I haven't thought very hard about the
implications, but as long as the change in VACUUM's behavior extends
only to the live-tuple count it reports, it seems like adjusting it
couldn't break anything too badly.
>> Another problem is that it looks like CREATE INDEX will set reltuples
>> to the total number of heap entries it chose to index, because that
>> is what IndexBuildHeapScan counts. Maybe we should adjust that?
> You mean by only counting live tuples in IndexBuildHeapRangeScan,
> following whatever definition we end up using in VACUUM/ANALYZE?
Right. One issue is that, as I mentioned, the index AMs probably want to
think about total-tuples-indexed not live-tuples; so for their purposes,
what IndexBuildHeapScan currently counts is the right thing. We need to
look and see if any AMs are actually using that value rather than just
silently passing it back. If they are, we might need to go to the trouble
of computing/returning two values.
regards, tom lane
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: tgl@sss.pgh.pa.us, tomas.vondra@2ndquadrant.com, kommi.haribabu@gmail.com
Subject: Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means
In-Reply-To: <27720.1511042193@sss.pgh.pa.us>
* 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