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.
On 21.03.23 18:46, Andres Freund wrote:
I don't think we can find enough to make the impact zero bytes. It's also
not clear exactly what the impact of each byte would be (compared to
possible complications in other parts of the code, for example). But if
there are a few low-hanging fruit, it se
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
23 matches
Mail list logo
