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