Re: [HACKERS] Bad estimate on LIKE matching

2006-01-18 Thread Simon Riggs
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

Re: [HACKERS] Bad estimate on LIKE matching

2006-01-18 Thread Tom Lane
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

Re: [HACKERS] Bad estimate on LIKE matching

2006-01-18 Thread Magnus Hagander
> > 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

Re: [HACKERS] Bad estimate on LIKE matching

2006-01-18 Thread Simon Riggs
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