Re: [HACKERS] Big IN() clauses etc : feature proposal

From: Greg Stark <gsstark(at)mit(dot)edu>
To: PFC <lists(at)peufeu(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Big IN() clauses etc : feature proposal
Date: 2006-05-09 15:00:29
Message-ID: 8764kfz1iq.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance


PFC <lists(at)peufeu(dot)com> writes:

>
> I really like this. It's clean, efficient, and easy to use.
>
> This would be a lot faster than using temp tables.
> Creating cursors is very fast so we can create two, and avoid doing
> twice the same work (ie. hashing the ids from the results to grab categories
> only once).

Creating cursors for a simple plan like a single sequential scan is fast
because it's using the original data from the table. But your example was
predicated on this part of the job being a complex query. If it's a complex
query involving joins and groupings, etc, then it will have to be materialized
and there's no (good) reason for that to be any faster than a temporary table
which is effectively the same thing.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mitchell Skinner 2006-05-09 15:58:05 Re: [HACKERS] Big IN() clauses etc : feature proposal
Previous Message Tom Lane 2006-05-09 13:56:01 Re: current version: Patch - Have psql show current values

Browse pgsql-performance by date

  From Date Subject
Next Message Bruno Wolff III 2006-05-09 15:18:48 Re: Arguments Pro/Contra Software Raid
Previous Message Steve Atkins 2006-05-09 14:41:16 Re: Arguments Pro/Contra Software Raid