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

Re: IN list processing performance (yet again)

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Dave Tenny <tenny(at)attbi(dot)com>
Cc: Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in>,pgsql-performance(at)postgresql(dot)org
Subject: Re: IN list processing performance (yet again)
Date: 2003-05-28 20:29:05
Message-ID: 20030528202905.GC6655@wolff.to (view raw or flat)
Thread:
Lists: pgsql-performance
On Wed, May 28, 2003 at 16:13:17 -0400,
  Dave Tenny <tenny(at)attbi(dot)com> wrote:
> Bruno Wolff III wrote:
> 
> I assume you mean something like:
> 
> test=# select million.id, million.val from million, (select 10000 as a 
> union select 20000 as a) t2 where million.id = t2.a;
>  id   |  val
> -------+-------
> 10000 |     0
> 20000 | 10000
> (2 rows)
> 
> Ouch!  That's deviant.   Haven't tried it yet and I cringe at the 
> thought of it, but I might take a run at it.  However that's going to
> run up the buffer space quickly.  That was one of my as yet unsnaswered 
> questions, what is the pragmatic buffer size limit
> for queries?

That is what I was referring to. I have used this in some cases where
I knew the list was small and I wanted to do a set difference without
loading a temporary table. Or to do an insert of multiple rows with
one insert statement.

> I'm /really/ hoping we'll come up with something better, like an 
> understanding of why IN lists are non-linear in the first
> place when the column is indexed, and whether it's fixable through some 
> other means or whether it's a bug that should be fixed.

It also might be worth seeing if the development version is going to
speed things up for you. Beta is one month away. My guess is that the
production release will be in September.

In response to

pgsql-performance by date

Next:From: Grega BremecDate: 2003-05-28 20:52:56
Subject: Re: Wildcard searches & performance question
Previous:From: Bruno Wolff IIIDate: 2003-05-28 20:24:18
Subject: Re: IN list processing performance (yet again)

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