On Fri, Dec 5, 2014 at 3:05 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> On what basis do you expect that? Every time you use a view, you're
>> using a pg_node_tree. Nobody's ever complained that having to reload
>> the pg_node_tree column was too slow, and I see no reason to suppose
>> that things would be any different here.
>>
>> I mean, we can certainly invent something new if there is a reason to
>> do so. But you (and a few other people) seem to be trying pretty hard
>> to avoid using the massive amount of infrastructure that we already
>> have to do almost this exact thing, which puzzles the heck out of me.
>
> My concern is how to do the routing of incoming tuples. I'm assuming it'd be
> significantly faster to compare two tuples than to run each tuple through a
> bunch of nodetrees.
As I said before, that's a completely unrelated problem.
To quickly route tuples for range or list partitioning, you're going
to want to have an array of Datums in memory and bseach it. That says
nothing about how they should be stored on disk. Whatever the on-disk
representation looks like, the relcache is going to need to reassemble
it into an array that can be binary-searched. As long as that's not
hard to do - and none of the proposals here would make it hard to do -
there's no reason to care about this from that point of view.
At least, not that I can see.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
