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
12 matches
Mail list logo
