Re: Performance difference in accessing differrent columns in a Postgres Table
On 29 July 2018 at 17:38, Dinesh Kumar 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. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Re: Performance difference in accessing differrent columns in a Postgres Table
David Rowley writes: > On 29 July 2018 at 17:38, Dinesh Kumar 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. regards, tom lane
Re: Performance difference in accessing differrent columns in a Postgres Table
2018-07-30 1:00 GMT+02:00 Tom Lane : > David Rowley writes: > > On 29 July 2018 at 17:38, Dinesh Kumar 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 > >
