Re: query very slow when enable_seqscan=on - Mailing list pgsql-bugs

From Tomasz Ostrowski
Subject Re: query very slow when enable_seqscan=on
Date
Msg-id 20060705083358.GA570@batory.org.pl
Whole thread Raw
In response to Re: query very slow when enable_seqscan=on  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #2512: pg_dump produces unrestorable output when table and serial sequence are not in the same schema
Next
From: Kris Jurka
Date:
Subject: Re: Fwd: [JDBC] Diffrence between 8.0.3 and 8.1.3