>
> Is the 10.3 plan parallelized at all? It's possible that the planner
> thinks a parallel seqscan is faster than a nonparallel indexscan
> (AFAIR, v10 doesn't have parallel indexscan).
>
Its not because its a delete operation, which doesn't support parallel
anything. Interestingly, the plain
Cory Tucker writes:
> relallvisible has a value of 0 for that table on both databases.
That would result in IOS being estimated at the same cost as a regular
indexscan, I believe, or very close to that anyway.
Is the 10.3 plan parallelized at all? It's possible that the planner
thinks a paralle
>
> Each table in your database has an entry in the pg_class table. Something
> like:
>
> SELECT relallvisible from pg_class where oid = 'build.household'::regclass;
>
> would show you the value, however, I think a problem here is unlikely
> since that would just control the likelihood of an index-
'On 30 March 2018 at 03:21, Cory Tucker wrote:
>> Another possibility is that 10.3 sees the index-only scan as too expensive
>> because it thinks most of the table isn't all-visible. Comparing
>> pg_class.relallvisible values might be informative.
> I'm happy to try to dig into this one more, ho
>
> Another possibility is that 10.3 sees the index-only scan as too expensive
> because it thinks most of the table isn't all-visible. Comparing
> pg_class.relallvisible values might be informative.
>
> regards, tom lane
>
I'm happy to try to dig into this one more, howev
David Rowley writes:
> On 29 March 2018 at 18:26, Cory Tucker wrote:
>> The plan on 9.6 v 10.3 are effectively identical except in 9.6 the planner
>> decides to use an index only scan on the primary key and in 10.3 it does a
>> sequential scan. The problem is the sequential scan is for a table o
On 29 March 2018 at 18:26, Cory Tucker wrote:
> Hello all. I'm migrating a database from PG 9.6 to 10.3 and have noticed a
> particular query that is performing very badly compared to its 9.6
> counterpart.
>
> The plan on 9.6 v 10.3 are effectively identical except in 9.6 the planner
> decides t
Hello all. I'm migrating a database from PG 9.6 to 10.3 and have noticed a
particular query that is performing very badly compared to its 9.6
counterpart.
The plan on 9.6 v 10.3 are effectively identical except in 9.6 the planner
decides to use an index only scan on the primary key and in 10.3 it
