On Wed, 2006-01-18 at 10:37 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2006-01-17 at 13:53 +0100, Magnus Hagander wrote:
> >> Any way to teach the planner about this?
>
> > In a recent thread on -perform, I opined that this case could best be
> > solved by using d
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2006-01-17 at 13:53 +0100, Magnus Hagander wrote:
>> Any way to teach the planner about this?
> In a recent thread on -perform, I opined that this case could best be
> solved by using dynamic random block sampling at plan time followed by a
> direc
> > I have tried upping the statistics target up to 1000, with
> no changes.
>
> > Any way to teach the planner about this?
>
> In a recent thread on -perform, I opined that this case could
> best be solved by using dynamic random block sampling at plan
> time followed by a direct evaluation
On Tue, 2006-01-17 at 13:53 +0100, Magnus Hagander wrote:
> On this table, I do a query like:
> SELECT * FROM path WHERE path LIKE 'f:/userdirs/s/super_73/%'
>
> The estimate for this query is comlpetely off, which I beleive is the
> cause for a very bad selection of a query plan when it's used i
I have a table, "path", which is:
pathid | integer | not null default
nextval('path_pathid_seq'::regclass)
path | text| not null
Indexes:
"path_pkey" PRIMARY KEY, btree (pathid)
"path_name_idx" btree (path)
The table contains approx 1.2 million rows, of which all are unique.
(both
