From: Mladen Gogala <mladen.gogala@vmsinfo.com>
To: sthomas@peak6.com <sthomas@peak6.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: [HACKERS] Slow count(*) again...
Date: Thu, 03 Feb 2011 17:03:07 -0500
Message-ID: <4D4B261B.6010303@vmsinfo.com> (raw)
In-Reply-To: <4D4B1F5B.4060403@peak6.com>
References: <201102012247.p11Ml6u02682@momjian.us>
<4D48914B.4050403@dunslane.net>
<4D489AD1.1010105@vmsinfo.com>
<AANLkTiknZi97dDwm7sHqy0EL7tpNEP9sY5uPV6AN+q=u@mail.gmail.com>
<4D499E55.4020107@vmsinfo.com>
<4D49A6B9.4060608@2ndquadrant.com>
<4D49C482.4010707@vmsinfo.com>
<4D49F0BA.9000901@2ndquadrant.com>
<4D4A16BF.1020304@vmsinfo.com>
<4D4A4844.3020409@2ndquadrant.com>
<4D4AD9F6.6040903@vmsinfo.com>
<4D4AE16E.9040807@peak6.com>
<4D4B17B4.9030406@vmsinfo.com>
<4D4B1F5B.4060403@peak6.com>
Shaun Thomas wrote:
> You missed the argument. The community, or at least the devs, see hints
> as an ugly hack. Do I agree? Not completely, but I can definitely
> understand the perspective. Saying every other "vendor" has hints is
> really just admitting every other vendor has a crappy optimizer. Is that
> something to be proud of?
>
This is funny? Everybody else has a crappy optimizer? That's a funny way
of looking at the fact that every other major database supports hints. I
would be tempted to call that a major missing feature, but the statement
that everybody else has a crappy optimizer sounds kind of funny. No
disrespect meant. It's not unlike claiming that the Earth is 6000 years old.
>
> And here's something I never saw you consider: hints making performance
> worse.
>
Sure. If you give me the steering wheell, there is a chance that I might
get car off the cliff or even run someone over, but that doesn't mean
that there is no need for having one. After all, we're talking about the
ability to control the optimizer decision.
> Want to remove a reverse index scan? Reindex with DESC on the column
> being reversed. That was added in 8.3. Getting too many calls for nested
> loops when a merge or hash would be faster? Increase the statistics
> target for the column causing the problems and re-analyze. Find an
> actual bug in the optimizer? Tell the devs and they'll fix it. Just stay
> current, and you get all those benefits. This is true for any database;
> bugs get fixed, things get faster and more secure.
>
In the meantime, the other databases provide hints which help me bridge
the gap. As I said before: hints are there, even if they were not meant
to be used that way. I can do things in a way that I consider very
non-elegant. The hints are there because they are definitely needed.
Yet, there is a religious zeal and a fatwa against them.
--
Mladen Gogala
Sr. Oracle DBA
1500 Broadway
New York, NY 10036
(212) 329-5251
http://www.vmsinfo.com
The Leader in Integrated Media Intelligence Solutions
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: mladen.gogala@vmsinfo.com, sthomas@peak6.com
Subject: Re: [HACKERS] Slow count(*) again...
In-Reply-To: <4D4B261B.6010303@vmsinfo.com>
* 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