Re: Yet another abort-early plan disaster on 9.3 - Mailing list pgsql-performance

From Graeme B. Bell
Subject Re: Yet another abort-early plan disaster on 9.3
Date
Msg-id 9E62E5EE-3E0E-4871-84B4-34E82E1C8AC9@skogoglandskap.no
Whole thread Raw
In response to Re: Yet another abort-early plan disaster on 9.3  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Yet another abort-early plan disaster on 9.3  (Claudio Freire <klaussfreire@gmail.com>)
Re: Yet another abort-early plan disaster on 9.3  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
>> The existing cost estimation
>> code effectively assumes that they're perfectly uniformly distributed;
>> which is a good average-case assumption but can be horribly wrong in
>> the worst case.


Sorry, just an outsider jumping in with a quick comment.

Every year or two the core count goes up. Can/should/does postgres ever attempt two strategies in parallel, in cases
wherestrategy A is generally good but strategy B prevents bad worst case behaviour? Kind of like a Schrödinger's Cat
approachto scheduling. What problems would it raise? 

Graeme.



pgsql-performance by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Yet another abort-early plan disaster on 9.3
Next
From: Claudio Freire
Date:
Subject: Re: Yet another abort-early plan disaster on 9.3