Michael Paquier <michael@paquier.xyz> writes: > On Wed, Jul 10, 2019 at 12:51:28PM +0530, Amit Kapila wrote: >> It would be good if we can come up with something like that. It will >> be helpful for zheap, where in some cases we get different row >> ordering due to in-place updates. As of now, we try to add Order By >> or do some extra magic to get consistent row ordering.
> That was an issue for me as well when working with Postgres-XC when > the row ordering was not guaranteed depending on the number of nodes > (speaking of which Greenplum has the same issues, no?). Adding ORDER > BY clauses to a set of tests may make sense, but then this may impact > the plans generated for some of them..
Yeah, I do not want to get into a situation where we can't test queries that lack ORDER BY. Also, the fact that tableam X doesn't reproduce heap's row ordering is not a good reason to relax the strength of the tests for heap. So I'm wondering about some postprocessing that we could optionally apply. Perhaps the tools Melanie mentions could help.
Surprisingly, I have been working from a couple of days to use those Perl tools from Greenplum for Zedstore. As for Zedstore plans differ for many regress tests because relation size not being the same as heap and all. Also, for similar reasons, row orders change as well. So, to effectively use the test untouched to validate Zedstore and yes was thinking will help Zheap testing as well. I also tested the same for regressplans.sh and it will lift a lot of manual burden of investigating the results. As one can specify to completely ignore explain plan outputs from the comparison between results and expected. Will post patch for the tool, once I get in little decent shape.