Re: File system performance and pg_xlog (More info)

Steve Wampler wrote:
>
> Doug McNaught wrote:
> >
> > That makes sense to me. On "traditional" Unices, we could use the raw
> > character device for a partition (eg /dev/rdsk/* on Solaris), and on
> > Linux we'd use /dev/raw*, which is a mapping to a specific partition
> > established before PG startup.
>
> Small update - newer Linux kernels now support multiple raw devices
> through /dev/raw/raw*, though the mapping between raw (character)
> and block devices has to be recreated on each boot.

It would be very easy to do a lot of experimenting, and perhaps even more
efficient in the long run if we could:

pre-allocate table spaces, rather than only letting a table file grow, why not
allow pre-allocated tables files. I want xyz table to be 2.2G long. That way a
file system doesn't care about the periphery of a file.

ALTER [table index] name PREALLOCATE nn BLOCKS;

Vacuuming and space reuse would be an issue. You would propbably have to
implement a defragment routine, or some sort of free block list.
After the preallocated limit is hit, grow the file normally.

Second, allow tables and indexes to be created with arbitrary file names,
something like:

create table foo (this integer, that varchar) as file '/path/file';
create index foo_ndx on foo (this) as file '/path2/file1';

If you do not specify a file, then it behaves as before.

I suspect that these sorts of modifications are either easy or hard. There
never is a middle ground on changes like this. The file name one is probably
easier than the preallocated block one.

--
I'm not offering myself as an example; every life evolves by its own laws.
------------------------
http://www.mohawksoft.com