Re: [HACKERS] Slow count(*) again...

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: [HACKERS] Slow count(*) again...
Дата
Msg-id AANLkTinsC5=TgpUoK_bZqQojuof4hu36=N_GXo2+MzBy@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Slow count(*) again...  (Mladen Gogala <mladen.gogala@vmsinfo.com>)
Ответы Re: [HACKERS] Slow count(*) again...
Re: [HACKERS] Slow count(*) again...
Список pgsql-performance
On Thu, Feb 3, 2011 at 5:39 PM, Mladen Gogala <mladen.gogala@vmsinfo.com> wrote:
> Actually, it is not unlike a religious dogma, only stating that "hints are
> bad". It even says so in the wiki. The arguments are

There's been considerably more output than "hints bad!  Hulk Smash!"

> 1) Refusal to implement hints is motivated by distrust toward users, citing
> that some people may mess things up.

It's more about creating a knob that will create more problems than it
solves.  Which I get.  And making sure that if you make such a knob
that it'll do the least damage and give the most usefulness.  Until a
good proposal and some code to do it shows up, we're all just waving
our hands around describing different parts of the elephant.

> 2) All other databases have them. This is a major feature and if I were in
> the MySQL camp, I would use it as an
>  argument. Asking me for some "proof" is missing the point. All other
> databases have hints precisely because
>  they are useful.

Uh, two points.  1: Argumentum Ad Populum.  Just because it's popular
doesn't mean it's right. 2: Other databases have them because their
optimizers can't make the right decision even most of the time.  Yes
they're useful, but like a plastic bad covering a broken car window,
they're useful because they cover something that's inherently broken.


> Assertion that only Postgres is so smart that can operate
> without hints doesn't match the
>  reality.

Again, you're twisting what people have said.  the point being that
while postgresql makes mistakes, we'd rather concentrate on making the
planner smarter than giving it a lobotomy and running it remotely like
a robot.


> As a matter of fact, Oracle RDBMS on the same machine will
> regularly beat PgSQL in performance.

Yes.  And this has little to do with hints.  It has to do with years
of development lead with THOUSANDS of engineers who can work on the
most esoteric corner cases in their spare time.  Find the pg project a
couple hundred software engineers and maybe we'll catch Oracle a
little quicker.  Otherwise we'll have to marshall our resources to do
the best we can on the project ,and that means avoiding maintenance
black holes and having the devs work on the things that give the most
benefit for the cost.  Hints are something only a tiny percentage of
users could actually use and use well.

Write a check, hire some developers and get the code done and present
it to the community.  If it's good and works it'll likely get
accepted.  Or use EDB, since it has oracle compatibility in it.

>  That has been my experience so far.   I even posted counting query results.
> 3) Hints are "make it or break it" feature. They're absolutely needed in the
> fire extinguishing situations.

I've been using pg since 6.5.2.  I've used Oracle since version 8 or
so.  I have never been in a situation with postgresql where I couldn't
fix the problem with either tuning, query editing, or asking Tom for a
patch for a problem I found in it.  Turnaround time on the last patch
that was made to fix my problem was somewhere in the 24 hour range.
If Oracle can patch their planner that fast, let me know.

> I see no arguments to say otherwise and until that ridiculous "we don't want
> hints" dogma is on wiki, this is precisely what it is:  a dogma. Dogmas do
> not change and I am sorry that you don't see it that way. However, this
> discussion

No, it's not dogma, you need to present a strong coherent argument,
not threaten people on the list etc.

В списке pgsql-performance по дате отправления:

Предыдущее
От: Conor Walsh
Дата:
Сообщение: Re: [HACKERS] Slow count(*) again...
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: [HACKERS] Slow count(*) again...