| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com> |
| Subject: | Re: Test timings are increasing too fast for cfbot |
| Date: | 2026-03-25 22:09:36 |
| Message-ID: | CAApHDvo+aLV4XbiFzyuhX_aZa7uETar6Fb_OGya1WzHrvftEDw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 25 Mar 2026 at 16:15, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Code wise, the most immediately noticeable things are
> 3) verify_compact_attribute(), pretty spread around
We do now have TupleDescFinalize(), where those could be checked just
once rather than on each call to TupleDescCompactAttr(). That's not
quite as watertight a guarantee as someone could change the
FormData_pg_attribute after TupleDescFinalize(). Just doing it in
TupleDescFinalize() would at least still catch the places where people
forget to call populate_compact_attribute() before
TupleDescFinalize().
I would have expected this to be a little less overhead now since
d8a859d22 removed the calls to TupleDescCompactAttr() in the main
deforming routine. Maybe I should just make that change in the other
deformers...? Do you have an idea of which callers of
verify_compact_attribute() are causing the most overhead?
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2026-03-25 22:10:25 | Re: Change default of jit to off |
| Previous Message | Bharath Rupireddy | 2026-03-25 22:06:14 | Re: LockHasWaiters() crashes on fast-path locks |