Re: Custom Plan node

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, PgHacker <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: Custom Plan node
Date: 2013-09-09 17:31:22
Message-ID: 20130909173122.GS2706@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> But, I guess I'm not yet convinced that one-for-one substitution of
> nodes is impossible even with something about this simple.

Couldn't that be done with hooks in those specific plan nodes, or
similar..? Of course, as Tom points out, that wouldn't address how the
costing is done and it could end up being wrong if the implementation of
the node is completely different.

All that said, I've already been wishing for a way to change how Append
works to allow for parallel execution through FDWs; eg: you have a bunch
of foreign tables (say, 32) to independent PG clusters on indepentdent
pieces of hardware which can all execute a given request in parallel.
With a UNION ALL view created over top of those tables, it'd be great if
we fired off all the queries at once and then went through collecting
the responses, instead of going through them serially..

The same approach could actually be said for Appends which go across
tablespaces, if you consider that independent tablespaces mean
independent and parallelizable I/O access. Of course, all of this would
need to deal sanely with ORDER BY and LIMIT cases.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-09-09 17:44:33 Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
Previous Message Stephen Frost 2013-09-09 17:26:10 Re: Strange hanging bug in a simple milter