Re: NOT LIKE much faster than LIKE?

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Matteo Beccati <php(at)beccati(dot)com>, Andrea Arcangeli <andrea(at)cpushare(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: NOT LIKE much faster than LIKE?
Date: 2006-01-11 09:07:45
Message-ID: 1136970465.21025.527.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-performance

On Tue, 2006-01-10 at 22:40 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)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

In response to


Browse pgsql-performance by date

  From Date Subject
Next Message Andrea Arcangeli 2006-01-11 09:18:41 Re: NOT LIKE much faster than LIKE?
Previous Message Michael Fuhr 2006-01-11 09:00:08 Re: Index isn't used during a join.