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

Re: PG planning randomly ?

From: "Laurent Raufaste" <analogue(at)glop(dot)org>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: PG planning randomly ?
Date: 2008-02-26 20:05:24
Message-ID: 669dc9710802261205j42250581w9fcc8b2def694650@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
2008/2/26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> "Laurent Raufaste" <analogue(at)glop(dot)org> writes:
>
> > 2008/2/26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>
> >> If it's 8.2 or later then increasing the stats target for _comment.path
>  >> to 100 or more would likely help.
>
>  > I'm using PG 8.2.4.
>  > We are using 100 as default_statistics_target by default and all our
>  > column are using this value:
>
>
> Hmm, that ought to be enough to activate the better selectivity
>  estimator.
>
>  Unless ... did you update this database from a pre-8.2 DB that already
>  had contrib/ltree in it?  If so, did you just load the existing old
>  definition of ltree as part of your dump, or did you install 8.2's
>  version fresh?  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 <@.
>
>                         regards, tom lane
>

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

--
-- Name: <@; Type: OPERATOR; Schema: public; Owner: postgres
--
CREATE OPERATOR <@ (
    PROCEDURE = ltree_risparent,
    LEFTARG = ltree,
    RIGHTARG = ltree,
    COMMUTATOR = @>,
    RESTRICT = ltreeparentsel,
    JOIN = contjoinsel
);
ALTER OPERATOR public.<@ (ltree, ltree) OWNER TO postgres;

Our data was created on an older PG (8.1.x) but we installed 8.2.x
from scratch, only dumping the schema and the data in it. I used ltree
found in the 8.2.4 source.

Do you think an update of ltree, or better of the database will fix
the problem ?

We plan on upgrading to the 8.3 branch in the next weeks, but this
behavior can't wait this much as our servers are overburned from time
to time =(

Thanks for your help ;)

-- 
Laurent Raufaste
<http://www.glop.org/>

In response to

Responses

pgsql-performance by date

Next:From: Scott MarloweDate: 2008-02-26 20:06:24
Subject: Re: PG planning randomly ?
Previous:From: Tom LaneDate: 2008-02-26 17:59:39
Subject: Re: PG planning randomly ?

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