Re: [HACKERS] Range Merge Join v1 - Mailing list pgsql-hackers

From Andrew Borodin
Subject Re: [HACKERS] Range Merge Join v1
Date
Msg-id CAJEAwVFrvc_ude4=Rv53x1AM5-nZro0jEo2XydHMrA1A+bRyqw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Range Merge Join v1  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: [HACKERS] Range Merge Join v1  (Andrew Borodin <borodin@octonica.com>)
List pgsql-hackers
Hi, Jeff!

I'm planning to provide the review for this patch in future. I've done
some performance tesing (see attachment).
All in all, nothing important, everything works fine.
Tests were executed under current HEAD on Ubuntu 16 over MacBook Air.

I observe that:
1. Patch brings performance improvement for specified query
2. Performance improvement of Range Merge Join vs GiST Nested Loop
Join (on Index Only Scan) is between 4x and 6x
3. Performance improvement of RMJ with B-tree index vs GiST is between
4x and 10x
(due to lack of actually competing cases, here I omit T-tests, they
are not that important when speaking about 4x difference)
4. Range Merge Join is capable to consume expressional index with
exactly same effect as direct index
5. Other attributes residing in joined tables do not affect
performance improvement

I'll make code review some time later, probably next week. (I hope
there is no urge in this, since commitfest is in July, or is it
urgent?) BTW fixe typo in index specification of original performance
test (both indexes were for same table)

Best regards, Andrey Borodin.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Unportable implementation of background worker start
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Unportable implementation of background worker start