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

help / color / mirror / Atom feed
From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
To: pgsql-performance@postgresql.org
Subject: Re: Yet another abort-early plan disaster on 9.3
Date: Thu, 02 Oct 2014 07:59:00 -0600
Message-ID: <542D5A24.1080308@cs.utoronto.ca> (raw)
In-Reply-To: <CAHyXU0wFAKiwgybbEAX=597-MxtPGdf0bmQvRSJq9db1KTZ6nA@mail.gmail.com>
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>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

On 29/09/2014 9:00 AM, Merlin Moncure wrote:
> On Fri, Sep 26, 2014 at 3:06 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> The problem, as I see it, is different. We assume that if there are
>> 100 distinct values and you use LIMIT 1 that you would only need to
>> scan 1% of rows. We assume that the data is arranged in the table in a
>> very homogenous layout. When data is not, and it seldom is, we get
>> problems.
> Hm, good point -- 'data proximity'.  At least in theory, can't this be
> measured and quantified?  For example, given a number of distinct
> values, you could estimate the % of pages read (or maybe non
> sequential seeks relative to the number of pages) you'd need to read
> all instances of a particular value in the average (or perhaps the
> worst) case.   One way of trying to calculate that would be to look at
> proximity of values in sampled pages (and maybe a penalty assigned for
> high update activity relative to table size).  Data proximity would
> then become a cost coefficient to the benefits of LIMIT.
Latecomer to the conversation here, but it seems like this issue (unlike 
some) is really easy to recognize at runtime. The optimizer assumed the 
scan would access  O(1) pages; if the scan has not returned enough 
results after k pages, that would be a really good indication that it's 
time to rethink the plan, and probably before too much work has been 
done higher in the plan (esp. if there's any kind of buffering between 
operators, perhaps intentionally so in special cases like this)

Not sure pgsql has any dynamic reoptimization infrastructure in place, 
tho. If not, these sorts of dangerous plans are best left alone IMO.

Ryan



-- 
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: <542D5A24.1080308@cs.utoronto.ca>
Permalink:  ../542D5A24.1080308@cs.utoronto.ca/
Also on:    postgresql.org/message-id/542D5A24.1080308@cs.utoronto.ca

 · 

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: ryan.johnson@cs.utoronto.ca
  Subject: Re: Yet another abort-early plan disaster on 9.3
  In-Reply-To: <542D5A24.1080308@cs.utoronto.ca>

* 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