Skip site navigation (1) Skip section navigation (2)

Re: PG planning randomly ?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Laurent Raufaste" <analogue(at)glop(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: PG planning randomly ?
Date: 2008-02-26 21:57:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
"Laurent Raufaste" <analogue(at)glop(dot)org> writes:
> 2008/2/26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> ... I'm wondering if you have a definition of operator <@
>> that doesn't specify the new selectivity estimator.  Please try a
>> pg_dump -s and see what it shows as the definition of <@.

> Here's the first definition of the <@ operator in my dump:

>     PROCEDURE = ltree_risparent,
>     LEFTARG = ltree,
>     RIGHTARG = ltree,
>     COMMUTATOR = @>,
>     RESTRICT = ltreeparentsel,
>     JOIN = contjoinsel
> );

That's the right RESTRICT function, but what exactly did you mean by
"first definition"?  Are there more?

It may be that it's just not possible for the estimator to come up with
accurate rowcount estimates given the amount of info it has available.
The query you are complaining about confuses the issue quite a lot by
involving other issues.  Would you try just "explain analyze select 1
from _commment where path <@ '....';" for various typical path values,
and see if it's coming up with estimated rowcounts that are in the right
ballpark compared to the actual ones?

			regards, tom lane

In response to


pgsql-performance by date

Next:From: Tom LaneDate: 2008-02-26 21:59:33
Subject: Re: PG planning randomly ?
Previous:From: Joshua D. DrakeDate: 2008-02-26 21:03:39
Subject: Re: disabling an index without deleting it?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group