Just curious (and without having looked at a line of code),

If your idea works, would it be possible, or even a good idea, to 
have PostgreSQL extend the relation in a non-linear fashion? So, for 
a given statement, the second time it finds itself extending the 
relation it does so by 2 x pagesize, the third time, now having 
exhausted 3 pages, it extends the relation by 4 x pagesize, etc. 
Oracle has its STORAGE clause of the CREATE TABLE statement which 
allows for tuning of such things, but I'm wondering if PostgreSQL 
can/should do some adaptive allocation of disk space. Perhaps it 
might cut down on large bulk load times?

Just curious,

Mike Mascari
mascarm@mascari.com

-----Original Message-----
From:	Tom Lane [SMTP:tgl@sss.pgh.pa.us]

We have talked about avoiding this kernel call by keeping an accurate
EOF location somewhere in shared memory.  However, I just had what is
either a brilliant or foolish idea: who says that we absolutely must
insert the new tuple on the very last page of the table?  If it fits 
on
a page that's not-quite-the-last-one, why shouldn't we put it there?
If that works, we could just use "rel->rd_nblocks-1" as our initial
guess of the page to insert onto, and skip the lseek.  

Thu, 10 May 2001 20:03:45 -0400
Mike Mascari <mascarm@mascari.com>
RE: Getting rid of excess lseeks()
Mike Mascari <mascarm@mascari.com> writes:
> If your idea works, would it be possible, or even a good idea, to 
> have PostgreSQL extend the relation in a non-linear fashion?

The trick would be to ensure that the extra blocks actually got used
for something ... without more logic than is there now, all the backends
would glom onto the last new page and ignore the possibility of putting
tuples into the other pages you'd added.

The hack I've proposed (and am currently testing) doesn't really do
anything to reduce the per-page overhead of extending the relation.
What it does do is reduce the per-tuple overhead of adding tuples
to an extant last page.  Basically we are down to an lseek per block
instead of an lseek per tuple ...

			regards, tom lane

Thu, 10 May 2001 22:21:05 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Getting rid of excess lseeks() 