From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Save a few bytes in pg_attribute |
Date: | 2023-03-21 19:58:05 |
Message-ID: | 20230321195805.cj7to6ozivqrmial@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2023-03-21 19:59:29 | Re: Comment in preptlist.c |
Previous Message | David Rowley | 2023-03-21 19:48:16 | Re: Adjust Memoize hit_ratio calculation |