Re: Manipulating complex types as non-contiguous structures in-memory - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Manipulating complex types as non-contiguous structures in-memory
Date
Msg-id 38232.1430510361@sss.pgh.pa.us
Whole thread Raw
In response to Re: Manipulating complex types as non-contiguous structures in-memory  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Manipulating complex types as non-contiguous structures in-memory  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> Test for 3000 elements:

>                    Original     Patch
> Integer            55sec      8sec
> Numeric           341sec      8sec

> Quicksort is about 3x faster -- so a benefit of this patch is clear.

Yeah, the patch should pretty much blow the doors off any case that's
heavily dependent on access or update of individual array elements ...
especially for arrays with variable-length element type, such as numeric.

What I'm concerned about is that it could make things *slower* for
scenarios where that isn't the main thing being done with the arrays,
as a result of useless conversions between "flat" and "expanded"
array formats.  So what we need is to try to benchmark some cases
that don't involve single-element operations but rather whole-array
operations (on arrays that are plpgsql variables), and see if those
cases have gotten noticeably worse.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Manipulating complex types as non-contiguous structures in-memory
Next
From: Jim Nasby
Date:
Subject: Re: CTE optimization fence on the todo list?