Re: [GENERAL] Physical Database Configuration

From: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>
To: johnnnnnn <john(at)phaedrusdeinus(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: [GENERAL] Physical Database Configuration
Date: 2003-06-25 20:43:06
Message-ID: 3EFA095A.7090309@web.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

johnnnnnn wrote:

>On Wed, Jun 25, 2003 at 10:30:31AM -0500, Andrew Dunstan wrote:
>
>
>>DB2 looks good. I have horrid, horrid memories of wrestling with the
>>Oracle "extent" madness.
>>
>>
>
>I do think that it's worth providing additional access points to
>tablespaces, though. That is, it would make sense to me to allow
>"CREATE INDEX indexname IN spacename", instead of attaching an
>indexspace to a table.
>
>This is especially true with postgresql, since i've seen more than one
>proposal for multi-table indices. If we're spacing indices based on
>the table, it's unclear where a given multi-table index should go.
>
>It would also allow for other flexibilities, like putting join indices
>(on foreign keys) in one tablespace, with indices for aggregation or
>sorting in another tablespace.
>
>
I wonder why an index spanning multiple tables should be stored in a
different location than the tables itself. If we're talking about
derived tables, all data/index must be available at the same time to be
meaningful, so why not restrict them to the same tablespace? This sounds
like more flexibility than really useful to me.

The philosophy of pgsql is to let the os and the io system distribute
the load over disks and other resources, not to do it in the backend.
That's why we need much less organizational effort than other systems
that try to implement everything themselves, on raw devices etc.

Regards,
Andreas

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jan Wieck 2003-06-25 20:47:27 Re: Error message, which memory param should I increase?
Previous Message Mike Mascari 2003-06-25 20:25:54 Re: INSERT WHERE NOT EXISTS

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-06-25 20:47:07 Re: Feature freeze and the great elog changeover
Previous Message Josh Berkus 2003-06-25 20:40:43 Re: Two weeks to feature freeze