Re: Remaining 'needs review' patchs in July commitfest

On Tue, Jul 28, 2015 at 3:51 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> plpgsql raise statement with context
>
> Impasse. Everyone wants this feature in some form, but no consensus on
> whether to do this client-side or server-side.

+1 for server-side. Does anyone other than you even think that the
client side is a reasonable way to go?

>> dblink: add polymorphic result functions
>
>
> Seems pretty ugly to me to add a dummy argument to functions, just so that
> you can specify the result type. The problem it's trying to solve is real,
> though. Should we take it as it is, or wait for some cleaner approach?

+1 for take it. If we wait for something better, we may be waiting a long time.

>> Asynchronous execution on postgres-fdw
>
> If we're going to have some sort of general-purpose Parallel node support
> soon, should we just forget about this? Or is it still useful? This adds a
> fair amount of new infrastructure, for a fairly niche feature..

IMHO, that's an extremely important feature. I believe that it will
not be obsoleted by other parallelism work. Actually, I think that
some of the infrastructure that it introduces may be quite helpful for
parallelism as well, but I haven't looked at in detail yet. The core
design concern that I have is what to do about this:

Append
-> Scan
-> Scan
-> Scan

Right now, we start each scan when the previous scan finishes. But
what if - either through parallelism or through this patch - we could
launch scans 2, 3, etc. before scan 1 completes? If there's a Limit
node above this somewhere we may regret our decision bitterly. But if
there isn't, we may do an enormous amount of good by starting that
plan early on the speculation that we will in fact need the results
eventually.

I haven't applied a whole lot of brainpower to this problem yet; I'm
sort of hoping someone else will have a good idea. Kyotaro
Horiguchi's approach seems to be to say that we don't need to solve
this problem at this stage and that we should just not worry about the
possible waste of resources on the remote machine for now; fix it
later, as part of a future patch. I'm not terribly confident in that
approach, but I don't currently have anything better to propose.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company