pg.ddx.io pgsql-performance@postgresql.org mailing list archivehelp / color / mirror / Atom feed
From: Simon Riggs <simon@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Matteo Beccati <php@beccati.com>
Cc: Andrea Arcangeli <andrea@cpushare.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: NOT LIKE much faster than LIKE?
Date: Wed, 11 Jan 2006 09:07:45 +0000
Message-ID: <1136970465.21025.527.camel@localhost.localdomain> (raw)
In-Reply-To: <7924.1136950830@sss.pgh.pa.us>
References: <20060110014447.GB18474@opteron.random>
<24021.1136858688@sss.pgh.pa.us>
<20060110022303.GA20168@opteron.random>
<24372.1136861684@sss.pgh.pa.us>
<43C3799D.5030103@beccati.com>
<1625.1136915395@sss.pgh.pa.us>
<1136930796.21025.486.camel@localhost.localdomain>
<6398.1136931685@sss.pgh.pa.us>
<1136936205.21025.507.camel@localhost.localdomain>
<7924.1136950830@sss.pgh.pa.us>
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
view thread (26+ messages) latest in thread
Message-ID: <1136970465.21025.527.camel@localhost.localdomain> Permalink: ../1136970465.21025.527.camel@localhost.localdomain/ Also on: postgresql.org/message-id/1136970465.21025.527.camel@localhost.localdomain ·
reply
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Reply to all the recipients using the --to and --cc options: reply via email To: pgsql-performance@postgresql.org Cc: simon@2ndquadrant.com, tgl@sss.pgh.pa.us, php@beccati.com, andrea@cpushare.com Subject: Re: NOT LIKE much faster than LIKE? In-Reply-To: <1136970465.21025.527.camel@localhost.localdomain> * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox