It seems that the page-at-a-time-index-scan patch applied in the spring
caused a slight performance regression to merge joins. The btree
mark/restore became much more expensive, as btmarkpos now has to copy
the array of item pointers retrieved from the current index page. That
adds up, because merge join calls markpos for every tuple.
We can make markpos fast, if we make the copy lazily in _bt_steppage,
see attached patch.
I did some micro-benchmarking of merge join performance, see attached
test. Test results, on my laptop:
8_1_STABLE: 1.77 s
HEAD, with patch: 1.65 s
HEAD, without patch: 2.46 s
The results are pretty stable, within 0.1 s.
pgsql-hackers by date
|Next:||From: Alban Hertroys||Date: 2006-08-23 12:07:49|
|Subject: Re: Queries joining views|
|Previous:||From: Greg Stark||Date: 2006-08-23 11:54:08|
|Subject: Re: Tricky bugs in concurrent index build|
pgsql-patches by date
|Next:||From: Teodor Sigaev||Date: 2006-08-23 12:08:12|
|Subject: Re: [HACKERS] Use of backslash in tsearch2|
|Previous:||From: Karel Zak||Date: 2006-08-23 09:17:19|
|Subject: Leaving... (was: Re: [HACKERS] COPY view)|