Re: 9.3 Pre-proposal: Range Merge Join - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: 9.3 Pre-proposal: Range Merge Join
Date
Msg-id CAPpHfdvu+CSuGoMFFS34zA3tQEG3p7kjP4v=4_8cu71rwDx5mQ@mail.gmail.com
Whole thread Raw
In response to Re: 9.3 Pre-proposal: Range Merge Join  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Tue, Apr 17, 2012 at 12:12 AM, Jeff Davis <pgsql@j-davis.com> wrote:
On Mon, 2012-04-16 at 16:22 +0400, Alexander Korotkov wrote:

> There is a good overview article about spatial joins.
> http://www.cs.umd.edu/users/hjs/pubs/jacoxtods07.pdf

Thank you, that's exactly the kind of overview I was looking for.

> It shows that there is a lot of methods based on building temporaty
> indexes. It might mean that building of temporary GiST index is not a
> bad idea.

That had occurred to me, but I was hesitant to only use temp indexes. It
still doesn't really offer a good solution when both sides of the join
are relatively large (because of random I/O). Also the build speed of
the index would be more important than it is now.
Note, that amount of random I/O during GiST index build significanlty dicreased after my GSoC project for buffering GiST index build. However, GiST index build is still quite CPU-expensive. This problem could be evaded by support of another methods of index build (another than producing a lot of penalty and picksplit calls). Hilbert curve and similar methods could help here. Implementation of such methods would require extension of GiST interface.

------
With best regards,
Alexander Korotkov.

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Aggressive memory consumption in {ts,array}_typanalyze
Next
From: Peter Geoghegan
Date:
Subject: Re: Memory usage during sorting