Re: pgstatindex vs. !indisready
От | Noah Misch |
---|---|
Тема | Re: pgstatindex vs. !indisready |
Дата | |
Msg-id | 20231022210245.2f.nmisch@google.com обсуждение исходный текст |
Ответ на | Re: pgstatindex vs. !indisready (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pgstatindex vs. !indisready
|
Список | pgsql-hackers |
On Wed, Oct 04, 2023 at 09:00:23AM +0900, Michael Paquier wrote: > 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). Neither choice would harm the user experience in an important way, so I've followed your preference in the attached patch.
Вложения
В списке pgsql-hackers по дате отправления: