From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgstatindex vs. !indisready |
Date: | 2023-10-04 00:00:23 |
Message-ID: | ZRyrF7QHMYTj6xTq@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Oct 01, 2023 at 06:31:26PM -0700, Noah Misch wrote:
> The !indisvalid index may be missing tuples, yes. In what way does that make
> one of those four operations incorrect?
Reminding myself of what these four do, it looks that you're right and
that the state of indisvalid is not going to change what they report.
Still, I'd like to agree with Tom's point to be more conservative and
check also for indisvalid which is what the planner does. These
functions will be used in SELECTs, and one thing that worries me is
that checks based on indisready may get copy-pasted somewhere else,
leading to incorrect results where they get copied. (indisready &&
!indisvalid) is a "short"-term combination in a concurrent build
process, as well (depends on how long one waits for the old snapshots
before switching indisvalid, but that's way shorter than the period of
time where the built indexes remain valid).
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2023-10-04 00:05:52 | Re: Synchronizing slots from primary to standby |
Previous Message | Alexander Korotkov | 2023-10-04 00:00:09 | Re: Index range search optimization |