Re: 9.3 Pre-proposal: Range Merge Join

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 9.3 Pre-proposal: Range Merge Join
Date: 2012-04-16 21:19:53
Message-ID: CAPpHfdvu+CSuGoMFFS34zA3tQEG3p7kjP4v=4_8cu71rwDx5mQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 17, 2012 at 12:12 AM, Jeff Davis <pgsql(at)j-davis(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-04-16 21:20:03 Re: 9.3 Pre-proposal: Range Merge Join
Previous Message Noah Misch 2012-04-16 20:58:51 Aggressive memory consumption in {ts,array}_typanalyze