Re: Save a few bytes in pg_attribute

On 23.03.23 13:45, Peter Eisentraut wrote: My suggestion is to use this patch and then consider the column encryption patch as it stands now. I have committed this.

Re: Save a few bytes in pg_attribute

ndependent of this patch: Either we keep it or we remove it; there is no proposal to resize it. From cff1daee2f12b4d625b18e6a89cb5e033f7fdfa5 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Thu, 23 Mar 2023 11:46:05 +0100 Subject: [PATCH v2] Save a few bytes in pg_attribute attndims, attst

Re: Save a few bytes in pg_attribute

On Wed, 22 Mar 2023 at 10:42, Peter Eisentraut wrote: > > On 21.03.23 18:46, Andres Freund wrote: > > FWIW, I think we should consider getting rid of attcacheoff. I doubt it's > > worth its weight these days, because deforming via slots starts at the > > beginning anyway. The overhead of maintaini

Re: Save a few bytes in pg_attribute

On 21.03.23 18:46, Andres Freund wrote: FWIW, I think we should consider getting rid of attcacheoff. I doubt it's worth its weight these days, because deforming via slots starts at the beginning anyway. The overhead of maintaining it is not insubstantial, and it's just architecturally ugly to to

Re: Save a few bytes in pg_attribute

On Tue, 21 Mar 2023 at 23:05, Andres Freund wrote: > > Hi, > > On 2023-03-21 21:02:08 +0100, Matthias van de Meent wrote: > > On Tue, 21 Mar 2023 at 20:58, Andres Freund wrote: > > > On 2023-03-21 20:20:40 +0100, Matthias van de Meent wrote: > > > > Yes, attcacheoff is a tremendous performance bo

Re: Save a few bytes in pg_attribute

Hi, On 2023-03-21 21:02:08 +0100, Matthias van de Meent wrote: > On Tue, 21 Mar 2023 at 20:58, Andres Freund wrote: > > On 2023-03-21 20:20:40 +0100, Matthias van de Meent wrote: > > > Yes, attcacheoff is a tremendous performance boon in many cases. > > > > Which? We don't use fastgetattr() in ma

Re: Save a few bytes in pg_attribute

Hi, On 2023-03-21 15:26:38 -0400, Tom Lane wrote: > Matthias van de Meent writes: > > ... with that patch we actually don't need the attcacheoff in the > > pg_atttribute struct: it only needs to be present in the derived > > "TupleAttrAlignData" structs which carry the > > length/alignment/storag

Re: Save a few bytes in pg_attribute

On Tue, 21 Mar 2023 at 20:58, Andres Freund wrote: > > Hi, > > On 2023-03-21 20:20:40 +0100, Matthias van de Meent wrote: > > On Tue, 21 Mar 2023 at 19:55, Tom Lane wrote: > > > > > > Andres Freund writes: > > > > FWIW, I think we should consider getting rid of attcacheoff. I doubt > > > > it's

Re: Save a few bytes in pg_attribute

Hi, On 2023-03-21 20:20:40 +0100, Matthias van de Meent wrote: > On Tue, 21 Mar 2023 at 19:55, Tom Lane wrote: > > > > Andres Freund writes: > > > FWIW, I think we should consider getting rid of attcacheoff. I doubt it's > > > worth its weight these days, because deforming via slots starts at th

Re: Save a few bytes in pg_attribute

Matthias van de Meent writes: > ... with that patch we actually don't need the attcacheoff in the > pg_atttribute struct: it only needs to be present in the derived > "TupleAttrAlignData" structs which carry the > length/alignment/storage/byval info. Yeah, I was wondering about that too: keeping

Re: Save a few bytes in pg_attribute

On Tue, 21 Mar 2023 at 19:55, Tom Lane wrote: > > Andres Freund writes: > > FWIW, I think we should consider getting rid of attcacheoff. I doubt it's > > worth its weight these days, because deforming via slots starts at the > > beginning anyway. The overhead of maintaining it is not insubstantia

Re: Save a few bytes in pg_attribute

Andres Freund writes: > FWIW, I think we should consider getting rid of attcacheoff. I doubt it's > worth its weight these days, because deforming via slots starts at the > beginning anyway. The overhead of maintaining it is not insubstantial, and > it's just architecturally ugly to to update tupl

Re: Save a few bytes in pg_attribute

Hi, On 2023-03-21 18:15:40 +0100, Peter Eisentraut wrote: > On 21.03.23 17:43, Andres Freund wrote: > > > The context of my message was to do the proposed change for PG16 to buy > > > back > > > a few bytes that are being added by another feature > > How much would you need to buy back to "reach

Re: Save a few bytes in pg_attribute

On 21.03.23 17:43, Andres Freund wrote: The context of my message was to do the proposed change for PG16 to buy back a few bytes that are being added by another feature How much would you need to buy back to "reach parity"? I don't think we can find enough to make the impact zero bytes. It's

Re: Save a few bytes in pg_attribute

Hi, On 2023-03-21 17:36:48 +0100, Peter Eisentraut wrote: > On 21.03.23 00:51, Tom Lane wrote: > > Andres Freund writes: > > > On 2023-03-20 10:37:36 -0400, Tom Lane wrote: > > > > I agree that attinhcount could be narrowed, but I have some concern > > > > about attstattarget. IIRC, the limit on

Re: Save a few bytes in pg_attribute

On 21.03.23 00:51, Tom Lane wrote: Andres Freund writes: On 2023-03-20 10:37:36 -0400, Tom Lane wrote: I agree that attinhcount could be narrowed, but I have some concern about attstattarget. IIRC, the limit on attstattarget was once 1000 and then we raised it to 1. Is it inconceivable t

Re: Save a few bytes in pg_attribute

Hi, On 2023-03-20 11:00:12 +0100, Peter Eisentraut wrote: > After the discussion in [0] ff., I was looking around in pg_attribute and > noticed that we could possibly save 4 bytes. We could change both > attstattarget and attinhcount from int4 to int2, which together with some > reordering would

Re: Save a few bytes in pg_attribute

Andres Freund writes: > On 2023-03-20 10:37:36 -0400, Tom Lane wrote: >> I agree that attinhcount could be narrowed, but I have some concern >> about attstattarget. IIRC, the limit on attstattarget was once 1000 >> and then we raised it to 1. Is it inconceivable that we might >> want to rais

Re: Save a few bytes in pg_attribute

Hi, On 2023-03-20 10:37:36 -0400, Tom Lane wrote: > I agree that attinhcount could be narrowed, but I have some concern > about attstattarget. IIRC, the limit on attstattarget was once 1000 > and then we raised it to 1. Is it inconceivable that we might > want to raise it to 10 someday?

Re: Save a few bytes in pg_attribute

On Mon, 20 Mar 2023, 11:00 pm Peter Eisentraut, wrote: > After the discussion in [0] ff., I was looking around in pg_attribute > and noticed that we could possibly save 4 bytes. We could change both > attstattarget and attinhcount from int4 to int2, which together with > some reordering would sav

Re: Save a few bytes in pg_attribute

Tomas Vondra writes: > IMHO it'd be much better to just not store the statistics target for > attributes that have it default (which we now identify by -1), or for > system attributes (where we store 0). I'd bet vast majority of systems > will just use the default / GUC value. So if we're interest

Re: Save a few bytes in pg_attribute

On 3/20/23 15:37, Tom Lane wrote: > Peter Eisentraut writes: >> After the discussion in [0] ff., I was looking around in pg_attribute >> and noticed that we could possibly save 4 bytes. We could change both >> attstattarget and attinhcount from int4 to int2, which together with >> some reor

Re: Save a few bytes in pg_attribute

Peter Eisentraut writes: > After the discussion in [0] ff., I was looking around in pg_attribute > and noticed that we could possibly save 4 bytes. We could change both > attstattarget and attinhcount from int4 to int2, which together with > some reordering would save 4 bytes from the fixed po

Save a few bytes in pg_attribute

ns.) The attached patch seems to work. Thoughts? [0]: https://www.postgresql.org/message-id/20230313204119.4mkepdvixcxrwpsc%40awork3.anarazel.deFrom 400f44d18875c40605147c8d81793c6dcc46f8a6 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Mon, 20 Mar 2023 09:51:20 +0100 Subject: [PATCH]