public inbox for [email protected]
help / color / mirror / Atom feedRe: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.
3+ messages / 2 participants
[nested] [flat]
* Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.
@ 2024-08-27 10:14 David Rowley <[email protected]>
2024-08-28 06:58 ` Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables. Justin Clift <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: David Rowley @ 2024-08-27 10:14 UTC (permalink / raw)
To: Justin Clift <[email protected]>; +Cc: Tom Lane <[email protected]>; nikhil raj <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>; NIKITA PATEL <[email protected]>; Patel Khushbu <[email protected]>
On Tue, 27 Aug 2024 at 18:00, Justin Clift <[email protected]> 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.
David
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.
2024-08-27 10:14 Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables. David Rowley <[email protected]>
@ 2024-08-28 06:58 ` Justin Clift <[email protected]>
2024-08-29 06:49 ` Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables. David Rowley <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Justin Clift @ 2024-08-28 06:58 UTC (permalink / raw)
To: David Rowley <[email protected]>; +Cc: Tom Lane <[email protected]>; nikhil raj <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>; NIKITA PATEL <[email protected]>; Patel Khushbu <[email protected]>
On 2024-08-27 20:14, David Rowley wrote:
> On Tue, 27 Aug 2024 at 18:00, Justin Clift <[email protected]>
> 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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.
2024-08-27 10:14 Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables. David Rowley <[email protected]>
2024-08-28 06:58 ` Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables. Justin Clift <[email protected]>
@ 2024-08-29 06:49 ` David Rowley <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: David Rowley @ 2024-08-29 06:49 UTC (permalink / raw)
To: Justin Clift <[email protected]>; +Cc: Tom Lane <[email protected]>; nikhil raj <[email protected]>; pgsql-generallists.postgresql.org <[email protected]>; NIKITA PATEL <[email protected]>; Patel Khushbu <[email protected]>
On Wed, 28 Aug 2024 at 18:59, Justin Clift <[email protected]> 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
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-08-29 06:49 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-08-27 10:14 Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables. David Rowley <[email protected]>
2024-08-28 06:58 ` Justin Clift <[email protected]>
2024-08-29 06:49 ` David Rowley <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox