Re: BUG #18205: Performance regression with NOT NULL checks.

From: Andres Freund <andres(at)anarazel(dot)de>
To: Daniel Migowski <dmigowski(at)ikoffice(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #18205: Performance regression with NOT NULL checks.
Date: 2023-11-19 22:17:44
Message-ID: 20231119221744.qqb34x4fns3go3lb@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On 2023-11-19 21:15:37 +0000, Daniel Migowski wrote:
> Thank you for the detailed explanation. It surely has a reason to remove the
> previously used short-circuit in slot_getattr, at least in the special case
> when we

The short-circuit in slot_getattr() still exists, we just don't reach it in
this case.

> And yes, in my real world use case which I tried to understand I have a wide
> table with 81 columns, and I am using column 1,43,18,75 and filter by
> attribute 82,42, and 24.

Are most of the columns NULL or not?

> Don't know how to handle this, maybe I should rework the layout of all my
> tables and move the mostly used columns to the beginning.

It might also be worth to split the table into multiple tables and join when
necessary. Independent of this issue, relatively wide tuples, where you don't
use most of the columns, will cause unnecessary IO.

Greetings,

Andres

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2023-11-19 22:39:11 Re: BUG #18205: Performance regression with NOT NULL checks.
Previous Message Thomas Munro 2023-11-19 22:03:23 Re: BUG #18207: Turkiye LC Setting Error