Re: final patch - plpgsql: for-in-array - Mailing list pgsql-hackers

From Tom Lane
Subject Re: final patch - plpgsql: for-in-array
Date
Msg-id 5201.1290106619@sss.pgh.pa.us
Whole thread Raw
In response to Re: final patch - plpgsql: for-in-array  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: final patch - plpgsql: for-in-array
Re: final patch - plpgsql: for-in-array
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> what is a slow:

> a) repeated detoasting - access with subscripts - maybe detoasted
> values can be cached?
> b) evaluation of SRF expression - maybe call of SRF function can be
> simple expression,
> c) faster evaluation ro query

> The most important is @a.

Really?  Becase AFAICS array_unnest only detoasts the source array once,
and saves the value between calls.

array_unnest doesn't currently have any smarts about fetching slices
of an array.  I'm not sure how useful that would be in practice, since
(1) in most usages you probably run the function to the end and fetch
all the values anyway; (2) it's hard to see how to optimize that way
if the elements are varlena, which they most likely are in most usages
where this could possibly be a win.  But if Cedric's use-case is really
worth optimizing, I'd sure rather see the smarts for it in the general
purpose array_unnest function instead of buried in plpgsql's FOR logic.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Indent authentication overloading
Next
From: Alvaro Herrera
Date:
Subject: Re: describe objects, as in pg_depend