Jim, glad you are still around. Yes, we would love to get tablespaces
in 7.4. I think we need to think bigger and get something where we can
name tablespaces and place tables/indexes into these named spaces. I
can reread the TODO.detail stuff and give you an outline. How does that
sound?
Just wanted to pipe in here. I am still very interested in tablespaces ( I have many
database systems that are over
500GB and growing) and am willing to port my tablespace patch to 7.4. I have
everything (but only tested here) working
in 7.2 but the patch was not accepted. I didn't see a
On 28 Sep 2002 at 12:18, Tom Lane wrote:
Justin Clift [EMAIL PROTECTED] writes:
Shridhar Daithankar wrote:
Looks like we should have a subdirectory in database directory which stores
index.
That was my first thought also, but an alternative/additional approach
would be this (not
On 29 Sep 2002 at 0:43, Justin Clift wrote:
Shridhar Daithankar wrote:
The reason that I was thinking of having a different path per index
would be for high volume situations like this:
/dev/dsk1 : /pgdata - data here
/dev/dsk2 : /pgindexes1 - some indexes here
/dev/dsk3 : /pgindexes2 -
Am Samstag, 28. September 2002 10:17 schrieb Shridhar Daithankar:
(snip)
I have to disagree.. Completely.. This is like turning PG-Metadata into
registry...
And what happens when index starts splitting when it grows beyond 1GB in
size?
Putting indexes into a separate subdirectoy and
Hi all,
Am experimenting to find out what kind of performance gain are achieved
from moving indexes to a different scsi drives than the WAL files, than
the data itself, etc.
Have come across an interesting problem.
Have moved the indexes to another drive, then created symlinks to them.
Ran a
On 28 Sep 2002 at 17:08, Justin Clift wrote:
Have moved the indexes to another drive, then created symlinks to them.
Ran a benchmark against the database, REINDEX'd the tables, VACUUM FULL
ANALYZE'd, prepared to re-run the benchmark again and guess what?
The indexes were back on the
Shridhar Daithankar wrote:
snip
Looks like we should have a subdirectory in database directory which stores
index.
That was my first thought also, but an alternative/additional approach
would be this (not sure if it's workable):
- As each index already has a bunch of information stored
On 28 Sep 2002 at 17:51, Justin Clift wrote:
Shridhar Daithankar wrote:
snip
Looks like we should have a subdirectory in database directory which stores
index.
That was my first thought also, but an alternative/additional approach
would be this (not sure if it's workable):
- As
Shridhar Daithankar wrote:
snip
And what happens when index starts splitting when it grows beyond 1GB in size?
Having an index directory:
i.e. $PGDATA/data/oid/indexes/
(that's the kind of thing you mean isn't it?)
Sounds workable, and sounds better than the present approach.
The reason
Justin Clift dijo:
Hi,
Ran a benchmark against the database, REINDEX'd the tables, VACUUM FULL
ANALYZE'd, prepared to re-run the benchmark again and guess what?
The indexes were back on the original drive.
Yes, this is expected. Same for CLUSTER. They create a different
filenode and
On Sat, 2002-09-28 at 02:16, Shridhar Daithankar wrote:
On 28 Sep 2002 at 17:08, Justin Clift wrote:
Have moved the indexes to another drive, then created symlinks to them.
Ran a benchmark against the database, REINDEX'd the tables, VACUUM FULL
ANALYZE'd, prepared to re-run the benchmark
Justin Clift [EMAIL PROTECTED] writes:
Shridhar Daithankar wrote:
Looks like we should have a subdirectory in database directory which stores
index.
That was my first thought also, but an alternative/additional approach
would be this (not sure if it's workable):
See the tablespaces TODO
13 matches
Mail list logo
