From: Mladen Gogala <mladen.gogala@vmsinfo.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: david@lang.hm <david@lang.hm>
Cc: Craig Ringer <craig@postnewspapers.com.au>
Cc: Vitalii Tymchyshyn <tivv00@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: [HACKERS] Slow count(*) again...
Date: Thu, 03 Feb 2011 11:38:14 -0500
Message-ID: <4D4AD9F6.6040903@vmsinfo.com> (raw)
In-Reply-To: <4D4A4844.3020409@2ndquadrant.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>
Greg Smith wrote:
> Mladen Gogala wrote:
>
>> The techies at big companies are the guys who will or will not make it
>> happen. And these guys are not beginners. Appeasing them may actually
>> go a long way.
>>
>
> The PostgreSQL community isn't real big on appeasing people if it's at
> the expense of robustness or correctness, and this issue falls into that
> category.
With all due respect, I don't see how does the issue of hints fall into
this category? As I explained, the mechanisms are already there, they're
just not elegant enough. The verb "appease" doesn't convey the meaning
that I had in mind quite correctly. The phrase "target population" would
have described what I wanted to say in a much better way .
> There are downsides to that, but good things too. Chasing
> after whatever made people happy regardless of its impact on the server
> code itself has in my mind contributed to why Oracle is so bloated and
> MySQL so buggy, to pick two examples from my favorite horse to whip.
>
Well, those two databases are also used much more widely than Postgres,
which means that they're doing something better than Postgres.
Hints are not even that complicated to program. The SQL parser should
compile the list of hints into a table and optimizer should check
whether any of the applicable access methods exist in the table. If it
does - use it. If not, ignore it. This looks to me like a philosophical
issue, not a programming issue. Basically, the current Postgres
philosophy can be described like this: if the database was a gas stove,
it would occasionally catch fire. However, bundling a fire extinguisher
with the stove is somehow seen as bad. When the stove catches fire,
users is expected to report the issue and wait for a better stove to be
developed. It is a very rough analogy, but rather accurate one, too.
--
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, greg@2ndquadrant.com, robertmhaas@gmail.com, andrew@dunslane.net, bruce@momjian.us, tgl@sss.pgh.pa.us, david@lang.hm, craig@postnewspapers.com.au, tivv00@gmail.com
Subject: Re: [HACKERS] Slow count(*) again...
In-Reply-To: <4D4AD9F6.6040903@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