Skip site navigation (1) Skip section navigation (2)

Merge join performance

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Subject: Merge join performance
Date: 2006-08-23 11:57:44
Message-ID: 44EC42B8.7070708@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com


Attachment: markopt.diff
Description: text/x-patch (5.5 KB)
Attachment: mergejointest.sh
Description: application/x-shellscript (514 bytes)

Responses

pgsql-hackers by date

Next:From: Alban HertroysDate: 2006-08-23 12:07:49
Subject: Re: Queries joining views
Previous:From: Greg StarkDate: 2006-08-23 11:54:08
Subject: Re: Tricky bugs in concurrent index build

pgsql-patches by date

Next:From: Teodor SigaevDate: 2006-08-23 12:08:12
Subject: Re: [HACKERS] Use of backslash in tsearch2
Previous:From: Karel ZakDate: 2006-08-23 09:17:19
Subject: Leaving... (was: Re: [HACKERS] COPY view)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group