Re: Displaying and dumping of table access methods

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Subject: Re: Displaying and dumping of table access methods
Date: 2019-01-08 22:48:05
Message-ID: 20190108224805.GA21835@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 08, 2019 at 09:29:49AM -0800, Andres Freund wrote:
> On 2019-01-08 13:02:00 +0900, Michael Paquier wrote:
>> The specific-heap tests could be included as an extra module in
>> src/test/modules easily, so removing from the main tests what is not
>> completely transparent may make sense.
>
> Why does it need to be an extra module, rather than just extra regression
> files / sections of files that just explicitly specify the AM? Seems a
> lot easier and faster.

The point would be to keep individual Makefiles simpler to maintain,
and separating things can make it simpler. I cannot say for sure
without seeing how things would change though based on what you are
suggesting, and that may finish by being a matter of taste.

> In the core tests there's a fair number of things that can be cured by
> adding an ORDER BY to the tests, which seems sensible. We've added a lot
> of those over the years anyway.

When working on Postgres-XC I cursed about the need to add many ORDER
BY queries to ensure the ordering of tuples fetched from different
nodes, and we actually had an option to enforce the default
distribution used by tables, so that would be really nice to close the
gap.

> There's additionally a number of plans
> that change, which currently is handled by alternatives output files,
> but I think we should move to reduce those differences, that's probably
> not too hard.

Okay, that's not surprising. I guess it depends on how many alternate
files are needed and if it is possible to split things so as we avoid
unnecessary output in alternate files. A lot of things you are
proposing on this thread make sense in my experience.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-01-08 22:53:25 Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
Previous Message Tom Lane 2019-01-08 22:31:23 Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)