So while testing this patch I've found out that there is a pretty nasty
bug in HEAD as well as in my current formulation of the patch. Here
is an example using the regression database:
select count(*) from
(tenk1 a join tenk1 b on a.unique1=b.unique2)
left join tenk1 c on a.unique2 = b.unique
2012/4/18 Greg Stark
> On Tue, Apr 17, 2012 at 5:14 PM, Tom Lane wrote:
> > I've been hacking away on a patch to do this, and attached is something
> > that I think is pretty close to committable.
>
> [..]Even when some of us don't
> comment on some of the longer, more technical emails, we're d
On Tue, Apr 17, 2012 at 5:14 PM, Tom Lane wrote:
> I've been hacking away on a patch to do this, and attached is something
> that I think is pretty close to committable.
I have nothing to add but I just wanted to say thank you for taking
the time to write up this explanation. Even when some of us
Robert Haas writes:
> On Tue, Apr 17, 2012 at 3:05 PM, Tom Lane wrote:
>>> Personally, I find required_outer more clear. YMMV.
>> Perhaps. What's bothering me is the potential for confusion with outer
>> joins; the parameter-supplying rels are *not* necessarily on the other
>> side of an outer
On Tue, Apr 17, 2012 at 3:05 PM, Tom Lane wrote:
> Well, we already made a policy decision that we weren't going to try
> very hard to support merge joins inside parameterized subtrees, because
> the potential growth in planning time looked nasty. My thought was that
> we might resurrect the para
Robert Haas writes:
> On Tue, Apr 17, 2012 at 12:14 PM, Tom Lane wrote:
>> BTW, after writing the code for it I decided to remove creation of
>> parameterized MergeAppendPaths from allpaths.c, though there is still some
>> support for them elsewhere. On reflection it seemed to me that the code
>
Excerpts from Robert Haas's message of mar abr 17 15:46:23 -0300 2012:
> On Tue, Apr 17, 2012 at 12:14 PM, Tom Lane wrote:
> > The core of the patch is in the new functions get_baserel_parampathinfo
> > and get_joinrel_parampathinfo, which look up or construct ParamPathInfos,
> > and join_clause
On Tue, Apr 17, 2012 at 12:14 PM, Tom Lane wrote:
> I've been hacking away on a patch to do this, and attached is something
> that I think is pretty close to committable. It needs another going-over
> and some new regression test cases, but it seems to work, and it fixes a
> number of things besi
On Thu, Apr 12, 2012 at 3:27 PM, Tom Lane wrote:
> 1. Lobotomize add_path_precheck so it always returns true for a
> parameterized path. This sounds horrid, but in the test cases I'm using
> it seems that this only results in doing the full path construction for
> a very small number of additiona
I wrote:
> So I'm back to thinking we need to look explicitly at the rowcount
> comparison as well as all the existing conditions in add_path.
> One annoying thing about that is that it will reduce the usefulness of
> add_path_precheck, because that's called before we compute the rowcount
> estima
On Mon, Mar 5, 2012 at 1:02 PM, Tom Lane wrote:
> But it's nervous-making to be making
> decisions like that on the basis of rather small sets of queries.
I heartily agree.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers ma
Robert Haas writes:
> On Sun, Mar 4, 2012 at 12:20 AM, Tom Lane wrote:
>> One annoying thing about that is that it will reduce the usefulness of
>> add_path_precheck, because that's called before we compute the rowcount
>> estimates (and indeed not having to make the rowcount estimates is one
>>
On Sun, Mar 4, 2012 at 12:20 AM, Tom Lane wrote:
> After looking at the results, I think that the fallacy in what we've
> been discussing is this: a parameterized path may well have some extra
> selectivity over a less-parameterized one, but perhaps *not enough to be
> meaningful*. The cases I wa
Robert Haas writes:
> On Wed, Feb 29, 2012 at 6:01 PM, Tom Lane wrote:
>> (... thinks some more ...) No, that doesn't get us there, because that
>> doesn't establish that a more-parameterized path produces fewer rows
>> than some path that requires less parameterization, yet not none at
>> all.
On Wed, Feb 29, 2012 at 6:01 PM, Tom Lane wrote:
>> Well, my "evidence" is that a parameterized path should pretty much
>> always include a paramaterized path somewhere in there - otherwise,
>> what is parameterization doing for us?
>
> Well, yes, we know that much.
I didn't write what I meant to
Robert Haas writes:
> On Wed, Feb 29, 2012 at 2:08 PM, Tom Lane wrote:
>> I think you're just assuming that without any solid evidence. My point
>> is precisely that if the more-parameterized path *fails* to generate
>> fewer rows, we want add_path to notice that and throw it out (or at
>> least
On Wed, Feb 29, 2012 at 2:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 29, 2012 at 1:40 PM, Tom Lane wrote:
>>> Indeed, and the code already knows that. However, in this example, path
>>> A is capable of dominating the other three (being strictly less
>>> parameterized than them)
>The most obvious thing to do about this is to consider that one path can
>dominate another on cost only if it is both cheaper *and* produces no
>more rows. But I'm concerned about the cost of inserting yet another
>test condition into add_path, which is slow enough already. Has anyone
>got an id
Robert Haas writes:
> On Wed, Feb 29, 2012 at 1:40 PM, Tom Lane wrote:
>> Indeed, and the code already knows that. However, in this example, path
>> A is capable of dominating the other three (being strictly less
>> parameterized than them), and B and C are each capable of dominating D.
>> The p
On Wed, Feb 29, 2012 at 1:40 PM, Tom Lane wrote:
>> I am having trouble
>> constructing an example, but I feel like there might be cases where
>> it's possible to have path A, not parameterized, path B, parameterized
>> by R, and path C, parameterized by S, and maybe also path D,
>> parameterized
Robert Haas writes:
> On Tue, Feb 28, 2012 at 5:35 PM, Tom Lane wrote:
>> The most obvious thing to do about this is to consider that one path can
>> dominate another on cost only if it is both cheaper *and* produces no
>> more rows.
> Hmm. Are you sure that's the right rule?
On further reflec
On Tue, Feb 28, 2012 at 5:35 PM, Tom Lane wrote:
> The most obvious thing to do about this is to consider that one path can
> dominate another on cost only if it is both cheaper *and* produces no
> more rows.
Hmm. Are you sure that's the right rule? I am having trouble
constructing an example,
On Tue, Feb 28, 2012 at 10:35 PM, Tom Lane wrote:
> The flaw in this logic, of course, is that the seqscan might be cheaper
> than the parameterized indexscan, but *it produces a whole lot more
> rows*, meaning that any subsequent join will be a lot more expensive.
> Previously add_path didn't ha
23 matches
Mail list logo
