From: | Mischa Sandberg <mischa(dot)sandberg(at)telus(dot)net> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Partitioning / Clustering |
Date: | 2005-05-11 02:19:13 |
Message-ID: | 1115777953.42816ba1b4618@webmail.telus.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Quoting "Jim C. Nasby" <decibel(at)decibel(dot)org>:
> To the best of my knowledge no such work has been done. There is a
> project (who's name escapes me) that lets you run queries against a
> remote postgresql server from a postgresql connection to a different
> server, which could serve as the basis for what you're proposing.
Okay, if the following looks right to the powerthatbe, I'd like to start
a project. Here's the proposition:
"servername.dbname.schema.object" would change RangeVar, which would
affect much code. "dbname.schema.object" itself is not implemented in
8.0. So, simplicity dictates something like:
table pg_remote(schemaname text, connectby text, remoteschema text)
The pg_statistic info from a remote server cannot be cached in local
pg_statistic, without inventing pseudo reloids as well as a
pseudoschema. Probably cleaner to cache it somewhere else. I'm still
reading down the path that puts pg_statistic data where costsize can get
at it.
First step: find out whether one can link libpq.so to postmaster :-)
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-05-11 02:49:06 | Re: Partitioning / Clustering |
Previous Message | Tom Lane | 2005-05-11 02:17:47 | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |