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

From Tom Lane
Subject Re: Parallel append plan instability/randomness
Date
Msg-id 7400.1515390981@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parallel append plan instability/randomness  (Amit Khandekar <amitdkhan.pg@gmail.com>)
Responses Re: Parallel append plan instability/randomness  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Amit Khandekar <amitdkhan.pg@gmail.com> writes:
> The fact that b_star gets moved from 5th position to  the first
> position in the scans, indicates that it's cost shoots up from 1.04 to
> a value greater than 1.16. It does not look like a case where two
> costs are almost same due to which their positions swap sometimes. I
> am trying to figure out what else can it be ...

The gut feeling I had upon seeing the failure was that the plan shape
depends on the order in which rows happen to be read from the system
catalogs by a heapscan.  I've not tried to run that idea to ground yet.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Amit Khandekar
Date:
Subject: Re: Parallel append plan instability/randomness
Next
From: Simon Riggs
Date:
Subject: Re: Logical decoding fast-forward and slot advance