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
