From: | PFC <lists(at)boutiquenumerique(dot)com> |
---|---|
To: | "John A Meinel" <john(at)arbash-meinel(dot)com>, "Adam Haberlach" <adam(at)mediariffic(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Partitioning / Clustering |
Date: | 2005-05-10 17:29:59 |
Message-ID: | op.sqklj9ppth1vuj@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> SELECT row1, row2 FROM table1_on_machine_a NATURAL JOIN
> table2_on_machine_b
> WHERE restrict_table_1 AND restrict_table_2
> AND restrict_1_based_on_2;
I don't think that's ever going to be efficient...
What would be efficient would be, for instance, a Join of a part of a
table against another part of another table which both happen to be on the
same machine, because the partitioning was done with this in mind (ie. for
instance partitioning on client_id and keeping the information for each
client on the same machine).
You could build your smart pool daemon in pl/pgsql and use dblink ! At
least you have the query parser built-in.
I wonder how Oracle does it ;)
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2005-05-10 17:35:59 | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |
Previous Message | Jim C. Nasby | 2005-05-10 17:26:52 | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |