From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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-10-03 07:23:48 |
Message-ID: | CAFj8pRDxCGTZbFJ4CM2v+PS4OTy9Co9d2prwW407kYU9KdLbUQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2013/10/3 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > If you can do a update of some array in plpgsql now, then you have to
> work
> > with local copy only. It is a necessary precondition, and I am think it
> is
> > valid.
>
> If the proposal only relates to assignments to elements of plpgsql local
> variables, it's probably safe, but it's also probably not of much value.
> plpgsql has enough overhead that I'm doubting you'd get much real-world
> speedup. I'm also not very excited about putting even more low-level
> knowledge about array representation into plpgsql.
>
I looked to code, and I am thinking so this can be done inside array
related routines. We just have to signalize request for inplace update (if
we have a local copy).
I have not idea, how significant speedup can be (if any), but current
behave is not friendly (and for multidimensional arrays there are no
workaround), so it is interesting way - and long time I though about some
similar optimization.
Regards
Pavel
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2013-10-03 07:48:48 | Re: SSI freezing bug |
Previous Message | Tom Lane | 2013-10-03 07:14:59 | Re: ToDo: fast update of arrays with fixed length fields for PL/pgSQL |