From: Dmitry Ivanov <d.ivanov@postgrespro.ru>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Possible problem in Custom Scan API
Date: Tue, 11 Apr 2017 19:36:11 +0300
Message-ID: <e29ddd30-8ef9-4da5-a50b-2bb7b8c7198d@postgrespro.ru> (raw)
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Hi hackers,
I'm struggling to understand one particular thing about Custom Scan API.
As you may know, there's a function called use_physical_tlist(), which aims
to eliminate meaningless projections during query execution. Any scan node
(e.g. CustomScan) aims to take advantage of physical targetlists... except
for the IndexOnlyScan (for obvious reasons):
createplan.c, create_scan_plan():
if (use_physical_tlist(root, best_path, flags))
{
if (best_path->pathtype == T_IndexOnlyScan)
{
/* For index-only scan, the preferred tlist is the index's */
tlist = copyObject(((IndexPath *) best_path)->indexinfo->indextlist);
...
}
...
}
In theory, CustomScans should be able to use any Plan nodes (i.e.
'custom_plans' list), but as far as I can understand, there's no way to
override behavior of use_physical_tlist(), which means that we might see
something like this:
ERROR: variable not found in subplan target list
if we use child IndexOnlyScan and the index does not include some of the
relation's columns.
Is there any existing workaround?
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: d.ivanov@postgrespro.ru
Subject: Re: Possible problem in Custom Scan API
In-Reply-To: <e29ddd30-8ef9-4da5-a50b-2bb7b8c7198d@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox