Re: Save a few bytes in pg_attribute - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Save a few bytes in pg_attribute
Date
Msg-id 20230321195805.cj7to6ozivqrmial@awork3.anarazel.de
Whole thread Raw
In response to Re: Save a few bytes in pg_attribute  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: Save a few bytes in pg_attribute  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
List pgsql-hackers
Hi,

On 2023-03-21 20:20:40 +0100, Matthias van de Meent wrote:
> On Tue, 21 Mar 2023 at 19:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > Andres Freund <andres@anarazel.de> 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 tupledescs continually.
> >
> > I'd be for that if we can convince ourselves there's not a material
> > speed penalty.  As you say, it's quite ugly.
> 
> Yes, attcacheoff is a tremendous performance boon in many cases.

Which? We don't use fastgetattr() in many places these days. And in some quick
measurements it's a wash or small loss when deforming slot tuples, even when
the attcacheoff optimization would apply, because the branches for managing it
add more overhead than they safe.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Adjust Memoize hit_ratio calculation
Next
From: David Rowley
Date:
Subject: Re: Comment in preptlist.c