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

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Justin Clift <justin(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, nikhil raj <nikhilraj474(at)gmail(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, NIKITA PATEL <patelnikita1411(at)gmail(dot)com>, Patel Khushbu <patelkhushbu2067(at)gmail(dot)com>
Subject: Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.
Date: 2024-08-29 06:49:21
Message-ID: CAApHDvpKUtAjGHQhCVVfnNBLnWepgkz4Ze2daMpGeKaQz2Prag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Wed, 28 Aug 2024 at 18:59, Justin Clift <justin(at)postgresql(dot)org> wrote:
> Any idea who normally does those, and if it would be reasonable to add
> test(s) for the internal information tables?

These tend to get added along with features and along with of bug
fixes. I imagine any tests for the information_schema views would be
for the results of the views rather than for the expected plans.
However, that seems very separate from this as the bug has nothing to
do with information_schema. It just happens to be a query to an
information_schema view that helped highlight the bug. Those views
are often quite complex and so are the resulting plans. With tests
checking the expected EXPLAIN output, it's much better to give these a
very narrow focus otherwise the expected output could be too unstable
and the purpose of the test harder to determine for anyone working on
a new patch which results in a plan change of a preexisting test.
I've seen tests before rendered useless by people blindly accepting
the plan change without properly determining what the test is supposed
to be testing. That's much more likely to happen when the purpose of
the test is less clear due to some unwieldy and complex expected plan.
I managed to get a reproducer for this down to something quite simple.
Probably that or something similar would be a better test to make sure
this bug stays gone.

David

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Greg Sabino Mullane 2024-08-29 13:24:00 Re: PgBackRest Full backup and N/W reliability
Previous Message KK CHN 2024-08-29 06:21:54 PgBackRest Full backup and N/W reliability

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2024-08-29 07:01:34 Re: Little cleanup of ShmemInit function names
Previous Message Michael Paquier 2024-08-29 06:44:45 Re: Partitioned tables and [un]loggedness