Re: Any thoughts on a better approach to this query?

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Marc Mamin <M(dot)Mamin(at)intershop(dot)de>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Any thoughts on a better approach to this query?
Date: 2015-09-09 23:19:06
Message-ID: CAKFQuwadJNir8L6ft7Px65_BxqRxjE5=eaV5uAwP_Emq56hkYA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, Sep 5, 2015 at 8:36 AM, Marc Mamin <M(dot)Mamin(at)intershop(dot)de> wrote:

>
> array_not_nulls(array_agg(case when type='A' then link end ))as ar_a,
> array_not_nulls(array_agg(case when type='B' then link end ))as ar_b,
> array_not_nulls(array_agg(case when type NOT IN ('A', 'B') then link
> end)) as ar_others
>
>
​Yeah. I'm not sure why I didn't tend toward the array_agg approach since
I have made use of it previously. It cleans up a bit but not as much as I
was hoping - but also not seeing. The preponderance of case statements​

​ and array slicing is still present. I image trying to write some kind of
"shift" function but that doesn't mesh well with set theory; it seems to be
a procedural concept which I suspect would be considerably worse performing.

Thanks for the suggestion and once I get back on that project I'm intended
to do a barebones performance comparison of the two which I'll follow up
with.

David J.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Melvin Davidson 2015-09-09 23:51:48 Bugs with like_option in CREATE TABLE
Previous Message Michael Paquier 2015-09-09 23:14:46 Re: log_statement = 'mod' does not log all data modifying statements