Re: [HACKERS] Merge Join with an Index Optimization

2016-10-11 Thread Claudio Freire
On Sun, Sep 11, 2016 at 1:20 PM, Tom Lane wrote: > Michael Malis writes: >> As I understand it, a merge join will currently read all tuples from both >> subqueries (besides early termination). I believe it should be possible to >> take advantages of

Re: [HACKERS] Merge Join with an Index Optimization

2016-10-10 Thread Michael Malis
I discovered that the kind of join I proposed is called the leapfrog triejoin: https://arxiv.org/pdf/1210.0481v5.pdf

Re: [HACKERS] Merge Join with an Index Optimization

2016-09-11 Thread Thomas Munro
On Sun, Sep 11, 2016 at 11:07 PM, Michael Malis wrote: > On Sun, Sep 11, 2016 at 9:20 AM Tom Lane wrote: >> >> Michael Malis writes: >> >> As I understand it, a merge join will currently read all tuples from >> >> both >> >>

Re: [HACKERS] Merge Join with an Index Optimization

2016-09-11 Thread Michael Malis
On Sun, Sep 11, 2016 at 9:20 AM Tom Lane wrote: > Michael Malis writes: > >> As I understand it, a merge join will currently read all tuples from > both > >> subqueries (besides early termination). I believe it should be possible > to > >> take

Re: [HACKERS] Merge Join with an Index Optimization

2016-09-11 Thread Tom Lane
Michael Malis writes: > As I understand it, a merge join will currently read all tuples from both > subqueries (besides early termination). I believe it should be possible to > take advantages of the indexes on one or both of the tables being read from > to skip a large

[HACKERS] Merge Join with an Index Optimization

2016-09-10 Thread Michael Malis
Hi, As I understand it, a merge join will currently read all tuples from both subqueries (besides early termination). I believe it should be possible to take advantages of the indexes on one or both of the tables being read from to skip a large number of tuples that would currently be read. As an