Received: from localhost (maia-3.hub.org [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 91BF39FA12C
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 27 Aug 2007 12:56:15 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 44277-02 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 27 Aug 2007 12:56:05 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id B65479FA1B7
	for <pgsql-performance@postgresql.org>;
	Mon, 27 Aug 2007 12:56:05 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id l7RFtk1p001340;
	Mon, 27 Aug 2007 11:55:46 -0400 (EDT)
To: Willo van der Merwe <willo@mirasol.co.za>
cc: pgsql-performance@postgresql.org
Subject: Re: Performance issue 
In-reply-to: <46D2D496.60005@mirasol.co.za> 
References: <46D2D496.60005@mirasol.co.za>
Comments: In-reply-to Willo van der Merwe <willo@mirasol.co.za>
	message dated "Mon, 27 Aug 2007 15:41:42 +0200"
Date: Mon, 27 Aug 2007 11:55:46 -0400
Message-ID: <1339.1188230146@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200708/324
X-Sequence-Number: 26454

Willo van der Merwe <willo@mirasol.co.za> writes:
> I have something odd. I have Gallery2 running on PostgreSQL 8.1, and
> recently I upgraded to 8.1.9-1.el4s1.1 (64bit). The issue here really is
> how do I get PostgreSQL to work with their horrible code. The queries
> they generate look something like :
> SELECT blah, blah FROM table1, table2 WHERE <some relational stuff> AND
> id IN (<here a list of 42000+ IDs are listed>)

> On the previous version (which I can't recall what it was, but it was a
> version 8.1) the queries executed fine, but suddenly now, these queries
> are taking up-to 4 minutes to complete. I am convinced it's the
> parsing/handling of the IN clause.

You're wrong about that, because we have not done anything to change IN
planning in 8.1.x.  You might need to re-ANALYZE or something; it sounds
to me more like the planner has changed strategies in the wrong direction.

FWIW, 8.2 should be vastly more efficient than 8.1 for this sort of
query --- any chance of an upgrade?

			regards, tom lane