| 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 | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2002-09-28 11:08:36 | Re: hacker help: PHP-4.2.3 patch to allow restriction of | 
| Previous Message | Justin Clift | 2002-09-28 07:51:15 | Re: How to REINDEX in high volume environments? |