Re: parallelizing subplan execution - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: parallelizing subplan execution
Date
Msg-id m28wanhqsq.fsf@hi-media.com
Whole thread Raw
In response to Re: parallelizing subplan execution (was: explain and PARAM_EXEC)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Probably.  For one thing, you can't use fork(), because it won't work
> on Windows.
[...]
> query.  IOW, we're going to need, well, a connection pool in core.
> *ducks, runs for cover*

Well, in fact, you're slowly getting to the interesting^W crazy part of
it.

Now that you have a connection pool in core and a way to share the same
snapshot in more than one backend, won't you like for any HotStandby
slave to be able to share this snapshot too? And run the subplan there?

And while at it, you'd obviously (ahem) want the slave to run the pooler
too and have the possibility to ask its master if it still have a given
snapshot available. So that any transaction (session?) that turns out
not to be read-only can get transparently run on the master instead. So
the "snapshot too old" error get some more reasons to be.

Oh, of course, the next step after that is to have a single cluster be
both a slave and a master, so that we can talk about distributing the
data. Multi-nodes multi-TB (make it PB) is the future, didn't they say?

We now have nodes with only some of the data (that could be only some
partitions) and a way to give them subplans over the network, and a way
for them to run a write query on other hosts without telling the client
connection. Sounds fun, he?

Regards,
-- 
dim

And I don't do drugs, not even caffeine. :)


pgsql-hackers by date:

Previous
From: Jeroen Vermeulen
Date:
Subject: Re: Avoiding bad prepared-statement plans.
Next
From: Pavel Stehule
Date:
Subject: Plans for 9.1, Grouping Sets, disabling multiqueries, contrib module for string, plpgpsm, preload dictionaries