From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | 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-02 17:05:59 |
Message-ID: | CAFj8pRB8BFpx9xD43Sf3hAxG_V0bELPnZeWkzuGb3n_MVKr7JA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2013/10/2 Andres Freund <andres(at)2ndquadrant(dot)com>
> Hi,
>
> On 2013-10-02 18:56:51 +0200, Pavel Stehule wrote:
> > Hello
> >
> > this proposal is related to reported issue
> >
> http://www.postgresql.org/message-id/E1VQuta-0007Y4-Ip@wrigleys.postgresql.org
> >
> >
> > We can directly modify any fields of int, float, double arrays (when
> result
> > size will be immutable). This trick is used now for acceleration of some
> > aggregates.
> >
> > Ideas, comments?
>
> A specific array might be located directly on a buffer - starting to
> manipulate them inplace will lead to havoc in such scenarios. I don't
> think we have the infrastructure for detecting such cases.
>
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.
Pavel
>
> Greetings,
>
> Andres Freund
>
> --
> Andres Freund http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2013-10-02 17:17:52 | Re: hstore extension version screwup |
Previous Message | Andres Freund | 2013-10-02 17:01:49 | Re: ToDo: fast update of arrays with fixed length fields for PL/pgSQL |