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
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 |