Re: query very slow when enable_seqscan=on

Поиск
Список
Период
Сортировка
От Tomasz Ostrowski
Тема Re: query very slow when enable_seqscan=on
Дата
Msg-id 20060705083358.GA570@batory.org.pl
обсуждение исходный текст
Ответ на Re: query very slow when enable_seqscan=on  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #2512: pg_dump produces unrestorable output when table and serial sequence are not in the same schema
Следующее
От: Kris Jurka
Дата:
Сообщение: Re: Fwd: [JDBC] Diffrence between 8.0.3 and 8.1.3