RE: Getting rid of excess lseeks()

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.