Horton
Menu

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

Justin Clift <justin@postgresql.org>

View thread
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-27T06:00:13Z
Lists: pgsql-hackers, pgsql-general 
On 2024-08-27 11:50, David Rowley wrote:
> On Tue, 27 Aug 2024 at 13:40, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah, it looks like that condition on "table_name" is not getting
>> pushed down to the scan level anymore.  I'm not sure why not,
>> but will look closer tomorrow.
> 
> I was looking for the offending commit as at first I thought it might
> be related to Memoize. It does not seem to be.

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?

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.