Re: Yet another abort-early plan disaster on 9.3

Поиск
Список
Период
Сортировка
От Graeme B. Bell
Тема Re: Yet another abort-early plan disaster on 9.3
Дата
Msg-id 59B73250-D814-448E-8F92-DCC9730ED8B3@skogoglandskap.no
обсуждение исходный текст
Ответ на Re: Yet another abort-early plan disaster on 9.3  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Thanks for your replies everyone.

> You can't run two plans and have them both returning rows to the client,

That wasn't what I had in mind.

I can envisage cases where the worst case behaviour of one plan results in zero rows by the time the alternative plan
hasgenerated the complete result, never mind a single row (e.g. anything with LIMIT in it could fall into that
category).Maybe it's enough to alleviate the problems caused by planning heuristics known to have bad worst-case
performancethat is hard to avoid with a single-threaded approach? 

Providing we're not modifying data in the query, and providing we kill the 'loser' thread when either (the first result
/all results) come in, maybe there's value in letting them race and picking the best plan retrospectively. 


I guess it's going into another topic, but I wonder what % of DBs/queries look like this:

- little or no I/O thrash (e.g. tuples mostly in memory already or DB configured to have a relatively low
'random_page_cost')
- ordered results, or, the whole result set is being produced at once.
- SELECTs only

In my own work (national scale GIS) this is what most of our queries & query environments look like.

Graeme


On 30 Sep 2014, at 18:32, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> "Graeme B. Bell" <grb@skogoglandskap.no> writes:
>> 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? 
>
> You can't run two plans and have them both returning rows to the client,
> or performing inserts/updates/deletes as the case may be.
>
>             regards, tom lane
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance



В списке pgsql-performance по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Yet another abort-early plan disaster on 9.3
Следующее
От: Gavin Flower
Дата:
Сообщение: Re: Yet another abort-early plan disaster on 9.3