Kevin Brown <kevin@sysexperts.com> writes:
> Tom Lane wrote:
>> "Performance gains"? Name one.
> Instead of tables and their indexes being on the same platter, you'd
> be able to put them on separate platters. Sounds like it would likely
> yield a performance gain to me...
That has *nothing* to do with whether we name files after tables or not.
As Andrew pointed out, you don't really want people munging file
locations by hand anyway; until we have a proper tablespace
implementation, it's going to be tedious and error-prone no matter what.
> I'm not proposing that we return to calling the individual files (or
> the database they reside in) by name, only that we include a "type"
> identifier in the path so that objects of different types can be
> located on different spindles if the DBA so desires.
This has been proposed and rejected repeatedly in the tablespace
discussions. It's too limiting; and what's worse, it's not actually
any easier to implement than a proper tablespace facility. The
low-level I/O routines still need access to a piece of info they do
not have now. You may as well make it a tablespace identifier instead
of a file-type identifier.
The real point here is that "put the indexes on a different platter"
is policy. One should never confuse policy with mechanism, nor build a
mechanism that can only implement one policy.
regards, tom lane
