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

Re: pass in array to function for use by where clause? how optimize?

From: Anish Kejariwal <anishkej(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Rob Sargent <robjsargent(at)gmail(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: pass in array to function for use by where clause? how optimize?
Date: 2011-04-13 19:03:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-sql
Thanks Tom!  I've never used the any function before.  It totally fixed the
issue.  It's easier to code, makes more sense, and it fixed my performance

My guess is that the optimizer does not how to deal with



On Wed, Apr 13, 2011 at 9:15 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Rob Sargent <robjsargent(at)gmail(dot)com> writes:
> > On 04/13/2011 09:09 AM, Tom Lane wrote:
> >> Anish Kejariwal<anishkej(at)gmail(dot)com>  writes:
> >>> (select store_id, avg(sales) sales
> >>> from store
> >>> where group_id in(select $1[i] from generate_subscripts($1, 1) g(i))
> >> Seems like a pretty brute-force way to deal with the array.  Try
> >> where group_id = any($1)
> >> Not sure if it'll be a great deal faster, but it's at least easier to
> >> write.
> > Would adding a subservient function which actually uses the value of the
> > iteration (group_id) as a single parameter be of any use?
> Well, it'd be unlikely to solve the OP's actual complaint, which was
> performance.  Hiding the semantics from the planner via a function
> (which generally looks like a black box to the planner) is even worse
> than hiding the semantics in a sub-SELECT, which I think is probably
> the root cause of the performance issue here.
>                        regards, tom lane
> --
> Sent via pgsql-sql mailing list (pgsql-sql(at)postgresql(dot)org)
> To make changes to your subscription:

In response to

pgsql-sql by date

Next:From: Volkmar Herbst GCIDate: 2011-04-13 19:59:01
Subject: strange update behavior
Previous:From: CharlieDate: 2011-04-13 16:21:27
Subject: Re: [SQL] unnesting of array of different size explodes memory

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