Re: NOT LIKE much faster than LIKE? - Mailing list pgsql-performance

From Simon Riggs
Subject Re: NOT LIKE much faster than LIKE?
Date
Msg-id 1136970465.21025.527.camel@localhost.localdomain
Whole thread Raw
In response to Re: NOT LIKE much faster than LIKE?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: NOT LIKE much faster than LIKE?
List pgsql-performance
On Tue, 2006-01-10 at 22:40 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > I meant use the same sampling approach as I was proposing for ANALYZE,
> > but do this at plan time for the query. That way we can apply the
> > function directly to the sampled rows and estimate selectivity.
>
> I think this is so unlikely to be a win as to not even be worth spending
> any time discussing.  The extra planning time across all queries will
> vastly outweigh the occasional improvement in plan choice for some
> queries.

Extra planning time would be bad, so clearly we wouldn't do this when we
already have relevant ANALYZE statistics.

I would suggest we do this only when all of these are true
- when accessing more than one table, so the selectivity could effect a
join result
- when we have either no ANALYZE statistics, or ANALYZE statistics are
not relevant to estimating selectivity, e.g. LIKE
- when access against the single table in question cannot find an index
to use from other RestrictInfo predicates

I imagined that this would also be controlled by a GUC, dynamic_sampling
which would be set to zero by default, and give a measure of sample size
to use. (Or just a bool enable_sampling = off (default)).

This is mentioned now because the plan under consideration in this
thread would be improved by this action. It also isn't a huge amount of
code to get it to work.

Best Regards, Simon Riggs


pgsql-performance by date:

Previous
From: Michael Fuhr
Date:
Subject: Re: Index isn't used during a join.
Next
From: Andrea Arcangeli
Date:
Subject: Re: NOT LIKE much faster than LIKE?