From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com>, James Coleman <jtc331(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Maxim Ivanov <hi(at)yamlcoder(dot)me>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Peter Geoghegan <pg(at)bowt(dot)ie> |
Subject: | Re: Use of additional index columns in rows filtering |
Date: | 2023-07-19 18:03:43 |
Message-ID: | dd819e32-107c-4208-a3a6-aa018112c150@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/19/23 19:17, Jeff Davis wrote:
> On Wed, 2023-07-19 at 11:16 +0200, Tomas Vondra wrote:
>> I wonder if Andres was right (in the index prefetch thread) that
>> splitting regular index scans and index-only scans may not be ideal.
>> In
>> a way, this patch moves those nodes closer, both in capability and
>> code
>> (because now both use index_getnext_tid etc.).
>
> Yeah. I could also imagine decomposing the index scan node into more
> pieces, but I don't think it would work out to be a clean data flow.
> Either way, probably out of scope for this patch.
>
OK
> For this patch I think we should just tweak the EXPLAIN output so that
> it's a little more clear what parts are index-only (at least if VM bit
> is set) and what parts need to go to the heap.
>
Makes sense, I also need to think about maybe not having duplicate
clauses in the two lists. What annoys me on that it partially prevents
the cost-based reordering done by order_qual_clauses(). So maybe we
should have three lists ... Also, some of the expressions count be
fairly expensive.
BTW could you double-check how I expanded the index_getnext_slot()? I
recall I wasn't entirely confident the result is correct, and I wanted
to try getting rid of the "while (true)" loop.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2023-07-19 18:13:48 | Re: ALTER TABLE SET ACCESS METHOD on partitioned tables |
Previous Message | Tristan Partin | 2023-07-19 18:03:21 | Re: Use COPY for populating all pgbench tables |