Re: Bad estimate on LIKE matching - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Bad estimate on LIKE matching
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE6C7EC8@algol.sollentuna.se
Whole thread Raw
In response to Bad estimate on LIKE matching  ("Magnus Hagander" <mha@sollentuna.net>)
List pgsql-hackers
> > 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 of the LIKE against the
> sample. This would yield a more precise selectivity and lead
> to the better plan. So it can be improved for the next release.

I was kinda hoping for something I could use in 8.1 :-) Even if it's an
ugly solution for now. (My current workaround of writing it to a temp
table and the joining to the temp table causes a reasonable plan, but
I'd like something slightly less ugly than that if possible..)

//Magnus


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: equivalence class not working?
Next
From: Leandro Guimarães Faria Corcete DUTRA
Date:
Subject: Re: Surrogate keys (Was: enums)