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(at)mascari(dot)com

-----Original Message-----
From: Tom Lane [SMTP:tgl(at)sss(dot)pgh(dot)pa(dot)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.