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 <kataoka@interwiz.jp>