Re: Is This A Set Based Solution?

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 18:38:52
Message-ID: 4f0jv2hhojpdon74o6btdrf0rub34dp1ol@4ax.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, 10 Mar 2007 08:26:32 +0300 (MSK), oleg(at)sai(dot)msu(dot)su (Oleg
Bartunov) wrote:
in <Pine(dot)LNX(dot)4(dot)64(dot)0703100824300(dot)400(at)sn(dot)sai(dot)msu(dot)ru>

>I don't know if you could change your schema. but I'd consider your
>problem as a overlapping arrays task and use contrib/intarray for that.

That's a nice piece of work, Oleg, and extremely quick. I played with
it and pored over the docs but it just seems to keep coming back to the
fact that all of the array type manipulations are column based as
opposed to row based. In fact, this from section 8.10.5 of the docs
confirms it:

Tip
Arrays are not sets; searching for specific array elements may be a sign
of database misdesign. Consider using a separate table with a row for
each item that would be an array element. This will be easier to search,
and is likely to scale up better to large numbers of elements.

I was able to clean up the function I originally posted removing the
extraneous LOOP and I'm more than happy with the performance. What's
funny is that the function as it now stands is what I initially obtained
by googling, but I mistakenly added the extra loop. :-)

What I finally came up with is here:
<r7viv2hr16uvmsb4tti398rr8oce4e1nvm(at)4ax(dot)com>

---
Stefan Berglund

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Brandon Aiken 2007-03-15 18:54:00 Re: Lifecycle of PostgreSQL releases
Previous Message Martijn van Oosterhout 2007-03-15 18:19:47 Re: plperl function called > once in cascading triggers