Re: ToDo: fast update of arrays with fixed length fields for PL/pgSQL

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(at)localhost(dot)vmware(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ToDo: fast update of arrays with fixed length fields for PL/pgSQL
Date: 2013-11-26 12:12:21
Message-ID: CAFj8pRBtqPrsrcRB9Q=OcGrs6BgU0PTqsPMiPzET6hPF_Dj2pg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2013/11/25 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>

> Heikki Linnakangas <heikki(at)localhost(dot)vmware(dot)com> writes:
> > In general, I'm not convinced this patch is worth the trouble. The
> > speedup isn't all that great; manipulating large arrays in PL/pgSQL is
> > still so slow that if you care about performance you'll want to rewrite
> > your function in some other language or use temporary tables. And you
> > only get a gain with arrays of fixed-length element type with no NULLs.
>
> > So I think we should drop this patch in its current form. If we want to
> > make array manipulation in PL/pgSQL, I think we'll have to do something
> > similar to how we handle "row" variables, or something else entirely.
>
> I think that this area would be a fruitful place to make use of the
> noncontiguous datatype storage ideas that we were discussing with the
> PostGIS guys recently. I agree that tackling it in the context of plpgsql
> alone is not a good way to go at it.
>
> I'm not saying this in a vacuum of information, either. Some of the guys
> at Salesforce have been poking at noncontiguous storage for arrays and
> have gotten nice speedups --- but their patch is for plpgsql only and
> only addresses arrays, which makes it enough of a kluge that I've not
> wanted to bring it to the community. I think we should work towards
> a general solution instead.
>

I am for general solution (because these issues are good performance
traps), but a early particular solution can be valuable for lot of users
too - mainly if general solution can carry in two, three years horizon

Regards

Pavel

>
> regards, tom lane
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-11-26 12:14:27 Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Previous Message Rajeev rastogi 2013-11-26 12:09:31 Re: PostgreSQL Service on Windows does not start. ~ "is not a valid Win32 application"