Re: Displaying and dumping of table access methods - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Displaying and dumping of table access methods
Date
Msg-id 20190108224805.GA21835@paquier.xyz
Whole thread Raw
In response to Re: Displaying and dumping of table access methods  (Andres Freund <andres@anarazel.de>)
Responses Re: Displaying and dumping of table access methods  (Dmitry Dolgov <9erthalion6@gmail.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
Next
From: Tom Lane
Date:
Subject: Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)