Skip site navigation (1) Skip section navigation (2)

Re: How to REINDEX in high volume environments?

From: "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in>
To: PostgreSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How to REINDEX in high volume environments?
Date: 2002-09-28 08:17:00
Message-ID: 3D95B2D4.19842.3D02976@localhost (view raw or flat)
Thread:
Lists: pgsql-hackers
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 each index already has a bunch of information stored stored for
> it, would it be possible to have an additional column added called
> 'idxpath' or something?
> 
>  - This would mean that the index location would be stable per index,
> and would allow for *really* high volume environments to keep different
> indexes on different drives.

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 mount/link that directory on a 
device that is on a separate SCSI channel is what I can think of as last drop 
of performance out of it..

Just a thought, as usual..

I don't know how much efforts it would take but if we have pg_xlog in separte 
configurable dir. now, putting indexes as well and having per database pg_xlog 
should be on the same line. The later aspect is also important IMO..

Bye
 Shridhar

--
VMS, n.:	The world's foremost multi-user adventure game.


In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2002-09-28 11:08:36
Subject: Re: hacker help: PHP-4.2.3 patch to allow restriction of
Previous:From: Justin CliftDate: 2002-09-28 07:51:15
Subject: Re: How to REINDEX in high volume environments?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group