Claudio Freire <klaussfre...@gmail.com> writes:
> On Fri, Dec 12, 2014 at 6:48 PM, Robert Haas <robertmh...@gmail.com> wrote:
>> I have very little idea what the API you're imagining would actually
>> look like from this description, but it sounds like a terrible idea.
>> We don't want to make this infinitely general. We need a *fast* way
>> to go from a value (or list of values, one per partitioning column) to
>> a partition OID, and the way to get there is not to call arbitrary
>> user code.
> I think this was mentioned upthread, but I'll repeat it anyway since
> it seems to need repeating.
> More than fast, you want it analyzable (by the planner). Ie: it has to
> be easy to prove partition exclusion against a where clause.
Actually, I'm not sure that's what we want. I thought what we really
wanted here was to postpone partition-routing decisions to runtime,
so that the behavior would be efficient whether or not the decision
could be predetermined at plan time.
This still leads to the same point Robert is making: the routing
decisions have to be cheap and fast. But it's wrong to think of it
in terms of planner proofs.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
