On Tue, Jul 28, 2015 at 3:51 PM, Heikki Linnakangas <hlinn...@iki.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers