Date: Wed, 5 Jul 2006 10:33:59 +0200
From: Tomasz Ostrowski <tometzky@batory.org.pl>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@postgresql.org
Subject: Re: query very slow when enable_seqscan=on
Message-ID: <20060705083358.GA570@batory.org.pl>
References: <20060703203105.GA2801@batory.org.pl>
	<7353.1151967946@sss.pgh.pa.us>
	<20060704083733.GA20102@batory.org.pl>
	<13853.1152021389@sss.pgh.pa.us>
	<20060704144406.GA21511@batory.org.pl>
	<25494.1152036954@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <25494.1152036954@sss.pgh.pa.us>
User-Agent: Mutt/1.4.2.1i

On Tue, 04 Jul 2006, Tom Lane wrote:

> Tomasz Ostrowski <tometzky@batory.org.pl> writes:
> > So why estimate regex expressions if there is no estimation possible?
> > Let's set this estimate to be pessimistic (match everything or
> > everything not null) and it will choose better plans.
> 
> Better plans for this specific example, worse plans for other cases.
> Life is not that simple.

It isn't. This worse plans will be choosen only when pattern/regex
matching is used and will be, say, 2 times worse.

What I'm trying to point out is that some people use regular
expressions for filtering rows. When the program is written it is
often impossible to know what data will be put into it. And when a
program is unexpectedly 2000 times slower than normal it is much
worse than if it is 2 times slower, but predictable.

I know Postgres uses probabilistic approach so there's always a
probability that the planner chooses very wrong. But this probability
is so small that it can be ignored. With pattern/regex matching it is
not.

Regards
Tometzky
-- 
...although Eating Honey was a very good thing to do, there was a
moment just before you began to eat it which was better than when you
were...
                                                      Winnie the Pooh