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? Tho
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 grea
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
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 : /pgind
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 b
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
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 be
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
Shridhar Daithankar wrote:
> And what happens when index starts splitting when it grows beyond 1GB in size?
Having an index directory:
i.e. $PGDATA/data//indexes/
(that's the kind of thing you mean isn't it?)
Sounds workable, and sounds better than the present approach.
The reason that I was
On 28 Sep 2002 at 17:51, Justin Clift wrote:
> 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):
>
> -
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):
- As each index already has a bunch of information stored stored f
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 or
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 b
13 matches
Mail list logo