Tom Lane wrote:
I've been testing this patch a bit, and I'm unable to measure any
consistent improvement in pgbench times (sometimes it seems to win,
and some other times it doesn't). And gprof still swears up and down
that PageAddItem is only about 0.1% of the runtime, which would make
it impossible to obtain more than an 0.1% speedup. I'm inclined to
write off your result as measurement error --- it's notoriously hard
to get reproducible results out of pgbench.
OK. I think that your environment is more realistic than mine. I
have been convinced to your result. Surely, my patch may not be allround.
I tried making a million-row table with just two int4 columns and then
duplicating it with CREATE TABLE AS SELECT. In this context gprof
shows PageAddItem as taking 7% of the runtime, which your patch knocks
down to 1.5%. This seems to be about the best possible real-world case,
though (the wider the rows, the fewer times PageAddItem can loop), and
so I'm still unconvinced that there's a generic gain here.
In fact, I have created this patch since I wants to make COPY FROM
faster. So, it is not rare case for me. There may be no generic gain
here, but I think it is very important to make COPY FROM and so on more
speedy. Of course, if we can prevent the increase in a page header,
it's better.
PS: If we were going to apply the patch, I'd be inclined to compensate
for the space usage by removing the pd_tli field, which isn't actually
ever used anywhere in the current code.
It is very a good idea if it's possible. I want you to surely think
positively very much.
--
Hiroki Kataoka <[EMAIL PROTECTED]>
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
