pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Graeme B. Bell <grb@skogoglandskap.no>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Merlin Moncure <mmoncure@gmail.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: Yet another abort-early plan disaster on 9.3
Date: Tue, 30 Sep 2014 12:32:37 -0400
Message-ID: <10321.1412094757@sss.pgh.pa.us> (raw)
In-Reply-To: <9E62E5EE-3E0E-4871-84B4-34E82E1C8AC9@skogoglandskap.no>
References: <541A2335.3060100@agliodbs.com>
	<CAHyXU0zSCWLYZ34fsgAGn9x+nFEwOih4ve3kyeYonTY6xG1Xbg@mail.gmail.com>
	<WM!2bfedb9f882c0aee19f96e138ce7ba810dc6737fca13f21c249ba37fd452020e43a863c0516a5aab9c7b1bd4f7201d15!@asav-3.01.com>
	<541C7891.7000902@agliodbs.com>
	<CAM-w4HODbu3jLFbENhUXmU3R6YQUQW2GZQOBzt3vHtVdUO5+hA@mail.gmail.com>
	<WM!1ae41f8d6a3ccc4760aa921f5bee325497ff91ea6bb56959742bfe645e3727f092c347cf598f62aba805d5b6535ebc8f!@asav-1.01.com>
	<541DC87F.3030800@agliodbs.com>
	<CAHyXU0xh8kFG6jiH3CLswTPiZTxJYsP==uaZP_w_FxHc0Kyqxg@mail.gmail.com>
	<WM!aa8d66f3329082c248d8e57896b3051be5691fe6550231e4f7388b7a9339864c4c89748426e4ef897c484b8998b7f996!@asav-1.01.com>
	<5420B71C.6010208@agliodbs.com>
	<CA+U5nMJqYiViG8Xu=OqJo5o7NbKgrBYC=Kn6nx-4AtKXidWvtw@mail.gmail.com>
	<CAHyXU0wFAKiwgybbEAX=597-MxtPGdf0bmQvRSJq9db1KTZ6nA@mail.gmail.com>
	<CA+U5nMKnwZVkvdaQP7Sm15-Emdwt+TgnW7-0xQJvZPtHu2Wsvw@mail.gmail.com>
	<13982.1412031637@sss.pgh.pa.us>
	<CA+U5nMKkHU7V_QVLD0uREy42_7ET_QAXWgc2UYJBnTesNkbH7! A@mail.gmail.com>
	<9E62E5EE-3E0E-4871-84B4-34E82E1C8AC9@skogoglandskap.no>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

"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 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance



view thread (60+ messages)  latest in thread

Message-ID: <10321.1412094757@sss.pgh.pa.us>
Permalink:  ../10321.1412094757@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/10321.1412094757@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: tgl@sss.pgh.pa.us, grb@skogoglandskap.no, simon@2ndquadrant.com, mmoncure@gmail.com, josh@agliodbs.com
  Subject: Re: Yet another abort-early plan disaster on 9.3
  In-Reply-To: <10321.1412094757@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox