From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Manuel Rigger <rigger(dot)manuel(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: ERROR: found unexpected null value in index |
Date: | 2019-07-11 21:20:07 |
Message-ID: | 19241.1562880007@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I wrote:
> Index-only scans already have the LP_DEAD fast path (don't return value)
> and the all_visible fast path (always return value), and otherwise they
> do a heap visit. If we can use a custom visibility test in the heap
> visit and not muck up the opportunity to set LP_DEAD when relevant, then
> it seems like using the IOS code path will do exactly what we want.
> Otherwise some finagling might be necessary. But it still might be
> cleaner than directly looking at HOT-update status.
> I'll take a look at that tomorrow if nobody beats me to it.
As far as I can tell, no special finagling is needed: if we just use
the regular index-only-scan logic then this all works the way we want,
and it's actually better than before because we get to skip heap visits
altogether when dealing with unchanging data. Attached is a patch
against HEAD that seems to do all the right things.
I'm a little dissatisfied with the fact that I had to duplicate the
all-visible checking logic out of nodeIndexonlyscan.c. Maybe we should
think about refactoring to avoid multiple copies of that? But that's
probably a task for a separate patch, if it's practical at all.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
fix-get_actual_variable_range-for-HOT-chains.patch | text/x-diff | 12.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2019-07-11 22:35:13 | Re: ERROR: found unexpected null value in index |
Previous Message | Andrew Gierth | 2019-07-11 17:26:52 | Re: The result of the pattern matching is incorrect when the pattern string is bpchar type |