Re: Performance difference in accessing differrent columns in aPostgres Table
От | Jeff Janes |
---|---|
Тема | Re: Performance difference in accessing differrent columns in aPostgres Table |
Дата | |
Msg-id | CAMkU=1zVhQ5k5d=YyHNyrigLUNTkOj4=YB17s9--3ts8H-SO=Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Performance difference in accessing differrent columns in aPostgres Table (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Performance difference in accessing differrent columns in aPostgres Table
Re: Performance difference in accessing differrent columns in aPostgres Table |
Список | pgsql-performance |
On Mon, Jul 30, 2018 at 12:11 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
2018-07-30 1:00 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:David Rowley <david.rowley@2ndquadrant.com> writes:
> On 29 July 2018 at 17:38, Dinesh Kumar <dns98944@gmail.com> wrote:
>> I found performance variance between accessing int1 and int200 column which
>> is quite large.
> Have a look at slot_deform_tuple and heap_deform_tuple. You'll see
> that tuples are deformed starting at the first attribute. If you ask
> for attribute 200 then it must deform 1-199 first.
Note that that can be optimized away in some cases, though evidently
not the one the OP is testing. From memory, you need a tuple that
contains no nulls, and all the columns to the left of the target
column have to be fixed-width datatypes. Otherwise, the offset to
the target column is uncertain, and we have to search for it.JIT decrease a overhead of this.
The bottleneck here is such a simple construct, I don't see how JIT could improve it by much.
And indeed, in my hands JIT makes it almost 3 times worse.
Run against ab87b8fedce3fa77ca0d6, I get 12669.619 ms for the 2nd JIT execution and 4594.994 ms for the JIT=off.
Cheers,
Jeff
Вложения
В списке pgsql-performance по дате отправления: