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
> 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 ;)
In response to
pgsql-performance by date
|Next:||From: Scott Marlowe||Date: 2008-02-26 20:06:24|
|Subject: Re: PG planning randomly ?|
|Previous:||From: Tom Lane||Date: 2008-02-26 17:59:39|
|Subject: Re: PG planning randomly ? |