From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Dinesh Kumar <dns98944(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Performance difference in accessing differrent columns in a Postgres Table |
Date: | 2018-07-30 04:11:46 |
Message-ID: | CAFj8pRC-vGCx6NiAO8uUakv00KDv=hPDd5zueFPf5RJe-Uzr+g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2018-07-30 1:00 GMT+02:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> > On 29 July 2018 at 17:38, Dinesh Kumar <dns98944(at)gmail(dot)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.
Regards
Pavel
> regards, tom lane
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2018-07-30 11:19:07 | Re: Performance difference in accessing differrent columns in a Postgres Table |
Previous Message | Tom Lane | 2018-07-29 23:00:59 | Re: Performance difference in accessing differrent columns in a Postgres Table |