From: | Stefan Berglund <sorry(dot)no(dot)koolaid(at)for(dot)me> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Is This A Set Based Solution? |
Date: | 2007-03-15 23:54:53 |
Message-ID: | a0njv25tv107j8o60tcrm98ce63jf9vr12@4ax.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 15 Mar 2007 15:46:33 -0500, bruno(at)wolff(dot)to (Bruno Wolff III)
wrote:
in <20070315204633(dot)GA2156(at)wolff(dot)to>
>On Mon, Mar 12, 2007 at 11:15:01 -0700,
> Stefan Berglund <sorry(dot)no(dot)koolaid(at)for(dot)me> wrote:
>>
>> I have an app where the user makes multiple selections from a list. I
>> can either construct a huge WHERE clause such as SELECT blah blah FROM
>> foo WHERE (ID = 53016 OR ID = 27 OR ID = 292 OR ID = 512) or I could
>> alternatively pass the string of IDs ('53016,27,292,512') to a table
>> returning function which TABLE is then JOINed with the table I wish to
>> query instead of using the unwieldy WHERE clause. The latter strikes me
>> as a far more scalable method since it eliminates having to use dynamic
>> SQL to construct the ridiculously long WHERE clause which will no doubt
>> ultimately bump up against parser length restrictions or some such.
>
>How big is huge?
>If the list of IDs is in the 1000s or higher, then it may be better to
>load the data into a temp table and ANALYSE it before running your query.
>Otherwise, for smaller lists the IN suggestion should work well in recent
>versions.
Sorry, huge was an exaggeration. I doubt it would ever approach 1000 -
more like a couple hundred. I'll look at it a little closer.
---
Stefan Berglund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Su | 2007-03-16 01:42:57 | About the new day-time saving rule |
Previous Message | Joshua D. Drake | 2007-03-15 23:51:18 | Re: pg_dumpall and version confusion |