Re: Parallel append plan instability/randomness - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Parallel append plan instability/randomness
Date
Msg-id 14123.1515441027@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parallel append plan instability/randomness  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Parallel append plan instability/randomness
List pgsql-hackers
I wrote:
> In the regression test case at hand, the startup costs are all zero so
> this change wouldn't improve the test case's stability.  So I'm thinking
> that in addition, it would be a good idea for these functions to break
> exact compare_path_costs ties in some arbitrary but deterministic way,
> rather than letting qsort() have the final say on what happens.  If the
> subplans were all simple relation scans we could order them by planner
> relid, but I'm not sure what to do if they're not.

Ah, I have an idea --- let's create a bms_compare() qsort comparator for
bitmapsets, and use that on the paths' relid sets.  It hardly matters
what the exact semantics of the comparator are, as long as it behaves
sanely for equal sets.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Jesper Pedersen
Date:
Subject: Re: [HACKERS] Proposal: Local indexes for partitioned table
Next
From: Robert Haas
Date:
Subject: Re: Parallel append plan instability/randomness