From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, decibel <decibel(at)decibel(dot)org>, Greg Smith <gsmith(at)gregsmith(dot)com>, jd(at)commandprompt(dot)com, Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>, Bernd Helmle <mailings(at)oopsware(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: The science of optimization in practical terms? |
Date: | 2009-02-18 23:37:08 |
Message-ID: | 27636.1235000228@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Wed, 2009-02-18 at 15:32 -0500, Tom Lane wrote:
>> An idea that I think has been mentioned before is to try to identify
>> cases where we can *prove* there is at most one row emitted by a
>> sub-path (eg, because of a unique index, DISTINCT subplan, etc).
> Proof seems best way forward. IIRC the reason we didn't do this before
> HOT is that unique index scans did often return many more than one row.
But those extra tuples didn't make it up to the point of the join, so
they weren't really a problem for nestloop speed. IMO the reason this
hasn't been done to date is that until recently we didn't have any
mechanism to ensure a plan got invalidated if some constraint it was
depending on (like uniqueness) went away. Now we do, so it would be
safe to rely on the constraint for proof purposes.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Adriano Lange | 2009-02-19 00:55:54 | Re: graph representation of data structures in optimizer |
Previous Message | Tom Lane | 2009-02-18 23:33:12 | Re: Re: [COMMITTERS] pgsql: Start background writer during archive recovery. |