From: | Maxime Schoemans <maxime(dot)schoemans(at)enterprisedb(dot)com> |
---|---|
To: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
Cc: | Aleksander Alekseev <aleksander(at)tigerdata(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [PATCH] Check that index can return in get_actual_variable_range() |
Date: | 2025-09-18 16:03:52 |
Message-ID: | 2BE82474-30B1-4AA6-B1E7-97B33F9FA428@enterprisedb.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 18 Sep 2025, at 15:36, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>
> Testing with the src/test/modules/treeb work in the patch series at [1], modifying treebcanreturn() to always return false and modifying _treeb_first(), _treeb_next(), and _treeb_endpoint() to set scan->xs_itup to NULL rather than to a tuple, without the patch there are a number of test failures with "ERROR: no data returned for index-only scan", but with the patch applied those errors still appear. They are raised by nodeIndexonlyscan.c at line 213, inside IndexOnlyNext(), suggesting that changing treebcanreturn() to return false was not enough to dissuade the planner from choosing the index for an index only scan.
>
> Is there a bug in how the system selects an index for an index-only scan? Or is the combination amcanorder=true && amcanreturn=NULL/false not a valid choice for an index? If the latter, shouldn't there be a check for that somewhere, or at least an Assert()?
After a short offline discussion with Mark, we determined that this issue was due to treebproperty still returning true for the AMPROP_RETURNABLE property. This was a small oversight in the testing, but does not indicate a bug in postgres.
From | Date | Subject | |
---|---|---|---|
Next Message | Corey Huinker | 2025-09-18 16:04:16 | Re: someone else to do the list of acknowledgments |
Previous Message | Corey Huinker | 2025-09-18 15:54:33 | Re: someone else to do the list of acknowledgments |