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

Re: 9.3 Pre-proposal: Range Merge Join

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, 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-17 02:17:51
Message-ID: 1334629071.19915.115.camel@jdavis (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, 2012-04-16 at 22:20 +0100, Simon Riggs wrote:
> On Mon, Apr 16, 2012 at 9:12 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> > 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.
> The thing I like most about temp indexes is that they needn't be temporary.
> I'd like to see something along the lines of demand-created optional
> indexes, that we reclaim space/maintenance overhead on according to
> some cache management scheme. More space you have, the more of the
> important ones hang around. The rough same idea applies to
> materialised views.

I think to make an informed decision, the next thing I need to do is
hack up a prototype version of my merge join idea, and see how well it
performs against an index nestloop today.

It seems to me that both approaches may have merit independently.

	Jeff Davis

In response to

pgsql-hackers by date

Next:From: AlexDate: 2012-04-17 03:26:39
Subject: Re: Bug tracker tool we need
Previous:From: Kyotaro HORIGUCHIDate: 2012-04-17 02:09:14
Subject: Re: A typo fix in a comment in xlog.c

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