Re: Partitioning / Clustering - Mailing list pgsql-performance

From Mischa Sandberg
Subject Re: Partitioning / Clustering
Date
Msg-id 1115777953.42816ba1b4618@webmail.telus.net
Whole thread Raw
In response to Re: Partitioning / Clustering  ("Jim C. Nasby" <decibel@decibel.org>)
Responses Re: Partitioning / Clustering
List pgsql-performance
Quoting "Jim C. Nasby" <decibel@decibel.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 :-)


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] "Hash index" vs. "b-tree index" (PostgreSQL
Next
From: Neil Conway
Date:
Subject: Re: Partitioning / Clustering