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 has generated 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 performance that 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@xxxxxxxxxxxxx> wrote: > "Graeme B. Bell" <grb@xxxxxxxxxxxxxxxxx> writes: >> Every year or two the core count goes up. Can/should/does postgres ever attempt two strategies in parallel, in cases where strategy A is generally good but strategy B prevents bad worst case behaviour? Kind of like a Schrödinger's Cat approach to 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@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
