Re: Performance difference in accessing differrent columns in aPostgres Table - Mailing list pgsql-performance

From Dinesh Kumar
Subject Re: Performance difference in accessing differrent columns in aPostgres Table
Date
Msg-id CAEe=mR=LZvEHHfSz+pvK=dRP0s8hF9kxh3rs93ri8Ejwr=b2aQ@mail.gmail.com
Whole thread Raw
In response to Re: Performance difference in accessing differrent columns in aPostgres Table  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-performance
Ok, will do that. Thanks a lot.

On Wed, Sep 5, 2018 at 9:37 PM Jeff Janes <jeff.janes@gmail.com> wrote:


On Wed, Sep 5, 2018 at 12:00 PM Jeff Janes <jeff.janes@gmail.com> wrote:
On Wed, Sep 5, 2018 at 12:21 AM Dinesh Kumar <dns98944@gmail.com> wrote:
Hi All,
I was wondering whether the case is solved or still continuing. As a Postgres newbie, I can't understand any of the terms (JIT, tuple deformation) as you mentioned above. Please anyone let me know , what is the current scenario.


JIT is a just-in-time compilation, which will be new in v11.  Tuple deforming is how you get the row from the on-disk format to the in-memory format.

Some people see small improvements in tuple deforming using JIT in your situation, some see large decreases, depending on settings and apparently on hardware.  But regardless, JIT is not going to reduce your particular use case (many nullable and actually null columns, referencing a high-numbered column) down to being constant-time operation in the number of preceding columns.  Maybe JIT will reduce the penalty for accessing a high-numbered column by 30%, but won't reduce the penalty by 30 fold.  Put your NOT NULL columns first and then most frequently accessed NULLable columns right after them, if you can.

Correction: NOT NULL columns with fixed width types first.  Then of the columns which are either nullable or variable width types, put the most frequently accessed earlier.

pgsql-performance by date:

Previous
From: Jeff Janes
Date:
Subject: Re: query gets very slow when :jsonb ?& operator is used
Next
From: Patrick Molgaard
Date:
Subject: Multi-second pauses blocking even trivial activity