Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.

Justin Clift <justin@postgresql.org>

From: Justin Clift <justin@postgresql.org>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, nikhil raj <nikhilraj474@gmail.com>, "pgsql-generallists.postgresql.org" <pgsql-general@lists.postgresql.org>, NIKITA PATEL <patelnikita1411@gmail.com>, Patel Khushbu <patelkhushbu2067@gmail.com>
Date: 2024-08-28T06:58:56Z
Lists: pgsql-hackers, pgsql-general
On 2024-08-27 20:14, David Rowley wrote:
> On Tue, 27 Aug 2024 at 18:00, Justin Clift <justin@postgresql.org> 
> wrote:
>> As a general thought, seeing that this might be an actual problem
>> should some kind of automated testing be added that checks for
>> performance regressions like this?
> 
> We normally try to catch these sorts of things with regression tests.
> Of course, that requires having a test that would catch a particular
> problem, which we don't seem to have for this particular case.  A
> performance test would also require testing a particular scenario, so
> I don't see why that's better.  A regression test is better suited as
> there's no middle ground between pass and fail.

Yeah, that's the kind of thing I was thinking.

Any idea who normally does those, and if it would be reasonable to add
test(s) for the internal information tables?

Regards and best wishes,

Justin Clift



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Avoid inserting PlaceHolderVars in cases where pre-v16 PG did not.

  2. Remove one memoize test case added by commit 069d0ff02.