The verdict comes from one of the corner stone contributors to Postgres.
Mr. Josh Berkus, in his naive writing style wrote the following:

http://tinyurl.com/68gu822

"Since so many DBAs are convinced that they need Hints, they demand that
DBMS vendors supply them. And if those DBAs work for large multinational
corporations, the DBMS vendors listen. Whether or not their engineers
think query hints are a good idea, or even work.

The developers who work on the PostgreSQL not-for-profit database
project, though, have the privilege of not implementing a bad idea just
because a lot of people seem to want it. Q.E.D."

That means that Postgres developers are not going to listen to the
requests of some lousy commercial DBA people, like myself. They're
artists and revolutionaries, not paid workers like me. They're the ones
who decide what will be in the stinkin' database, not toiling paid slaves
like me. If we don't like, we don't have to use it. Well, the verdict has
been made for me. I will not use it for any serious project. Thanks, Josh.

This is the biography of this colorful cornerstone of the Postgres
community:

"In the more colorful past, Josh has been a sculptor, a potter, a pastry
baker, a labor organizer, a lobbyist, a legal assistant and a
professional fundraiser. He likes to think that this gives him more
perspective than the average Silicon Valley geek, but he's probably
kidding himself. He has lived in the Upper Haight neighborhood of San
Francisco since 1993, and is unlikely to leave as long as rent control
exists."

I don't have any comments. Mr. Berkus summed it up beautifully. As long
as people like him decide about the direction of the database software,
Postgres has no future. None whatsoever. Economic crisis and rising
Oracle prices have brought forth Postgres as an apparent alternative, but
it was just a dream, not to be. Unless somebody wrestles this hapless
project from the incompetent hands of the former pastry baker and his
ilk, this project is doomed. I gave it a chance, I invested the necessary
effort, time and resources and found that the reason why Stonebraker's
Ingres has lost against Oracle are still valid. Michael Stonebraker is a
PhD and a marvelously capable entrepreneur. The company that I work for
uses Vertica and we are quite satisfied with it. If a major personality
and computer scientist like Stonebraker lost against Oracle, when RTI
and Oracle were on the more or less equal financial footing, I cannot
envision cognitively challenged types like Berkus produce anything else
but abysmal failure. Sorry, Postgres, this is where I get off this train.
Good luck and may the farce be with you.



--
http://mgogala.byethost5.com

Mladen Gogala <gogala.mladen (AT) gmail (DOT) com> wrote:
I was going to ask what your point was, but I guess you finally made it.

....good riddance.

- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Melbourne, FL ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur.

On Mon, 07 Feb 2011 15:18:06 +0000, Stuffed Crust wrote:

Not so fast, my dear friend. I decided to invest necessary effort and
write a patch for PostgreSQL which will add hints. If the patch doesn't
make it into the code, as I suspect it will not, I will try forking the
code.

I may not have a voice in the Postgres community, but I do have voice in
the Oracle community, and that is where Postgres is trying to recruit its
users from.

I decided that my investment in Postgres is too large to allow few
imbeciles and former pastry bakers to ruin it for religious reasons.



--
http://mgogala.byethost5.com

Hi,

On 2/5/2011 11:00 AM, Mladen Gogala wrote:
I guess I don't see the problem. If you don't like "product P"
(or, "product O" for that matter), then don't buy/use it. I
don't like Sony products so I don't buy or use them. There
are other vendors so I patronize those, instead.

If "product E" offers this feature, then why not buy/use *it*?

One of the advantages of "product P" over some of the others
is that you can "take ownership" of a particular port/version
("product G"?) and drive it in whatever direction you need
(something not possible for "mere mortals" with "product O"...
unless you have VERY deep pockets).

My plans are exactly this as my deployed environment is atypical
for any of the above mentioned "products" and I can add considerable
value by bending one to fit my needs.

Alternatively, you could, perhaps, *fund* the addition of
that feature to "product P" -- depending on your philosophical
and financial goals and capabilities.

YMWV, of course.
--don

On Mon, 07 Feb 2011 12:05:35 -0700, D Yuniskis wrote:

So you do patronize some vendors?

You are missing the point.

You'll probably be surprised, but there is a regular procedure with the
"product O" to request product enhancements. There is no religion at the
helm of the "product O" and there are no imbeciles who would put
something like this on the Internet: http://tinyurl.com/68gu822


There is another possibility: to write the patch myself and poke in the
nose cognitively challenged pastry bakers.





--
http://mgogala.byethost5.com

Hi,

On 2/7/2011 12:39 PM, Mladen Gogala wrote:
Sure! It's the classic "make-vs-buy" decision. It is simply
not cost/time effective for me to *make* a television (though
I suspect I am technically competent to do so). And, since
there are other vendors with "acceptable" offerings, I can
simply chose to buy one of those, instead.

The same is true of hardware components (I design embedded
systems), software tools and "components", etc. It's always
a tradeoff of buying something off-the-shelf vs. fabricating
something. There are costs to each approach -- many of which
are hidden and vary with the application (e.g., a long product
life-cycle adds considerable cost to the "buy" solutions as
many of those have long term availability issues).

<shrug> I guess I must be. :<

Presumably you are using PG because of some problem you see in O.
Yet, PG is "missing" a feature (that O apparently has) that you
consider important (i.e., there is a cost/benefit associated with
the presence/absence of this feature). OTOH, E seems to be PG
plus that "missing" feature (I am assuming this based solely
on your comments, here as I have no experience with the feature
in question nor it's presence or implementation in E vs O).

So, why not go with *E*?

In my case, the "enhancements" are very application specific.
I.e., there would be little use for them in the "general
population". As such, O would expect me to subsidize their
development (this makes sense). In return, I would want a
lifetime license to the *source* for that system so that
I could support it when/if O decided it was no longer in
their (financial) interests to do so.

This is "do-able". But, it is a huge PITA (been there, done
that, T-shirt to prove it). I.e., there is a huge *cost*
(and it is all "up front") to going this route. And, a
huge potential cost (risk) down the road when/if that
long term support becomes necessary. (I've worked on
$100K *products* that had to be redesigned when one or more
of the "components"/systems they relied on was "suddenly"
no longer available -- at ANY "reasonable" price)

Since there are alternatives, I can explore them with a
better control on the total "costs". For me, PG is one
of the alternatives available.

That was my point in "taking ownership" of a port. Subject to
the license terms, you are free to fork any branch of the
development tree and take it in whatever direction suits
your needs. The *advantage* of this is there is no need
to "negotiate" features or implementation -- do what *you*
want! Of course, the *disadvantage* is that *you* have to
do it! :<

If it makes sense "financially", then do it. Else, buy
something that already *does* it (you can pay now or pay
later but there are no free lunches).

--don

On Mon, 07 Feb 2011 13:28:39 -0700, D Yuniskis wrote:



I am not sure that EDB will be around long enough for the purchase to
make sense. There are many factors. One of the things that are really
infuriating is the fact that two of the Postgres committers are selling
the "E" product, which has hints as the killer feature, and advocating
against the hints in the open source version.
That does seem like a conflict of interest, to put it mildly.


--
http://mgogala.byethost5.com

On Tue, 08 Feb 2011 14:32:58 -0700, D Yuniskis wrote:

Lovely analogy, but, unfortunately, analogy doesn't produce logically
valid results. How, exactly, would hints be bad for me? There is no
perfect optimizer and I have seen situations in which hints are
necessary. That includes correlated data, bind variables and joins with
the predicate which is not an equality condition. Also, there are
situations, especially in porting projects, when quick and dirty
solutions are needed for pragmatic reasons. That speaks on the necessity
of hints.
Hints are not mandatory, so if you don't approve of them, you don't have
to use them. Hints are an option, available in any other database, except
PostgreSQL. Having that in mind, I fail to see why would having such an
option be bad?
Finally, on the more personal side of things, you obviously are a
Postgres user and so am I. I don't know whether you are OK with the
"gurus" telling you that you are dumber than a computer program, but I am
not OK with that. I consider that one of the stupidest and most insulting
pieces of "argumentation" that I've ever seen.


--
http://mgogala.byethost5.com

Hi,

On 2/9/2011 6:10 AM, Mladen Gogala wrote:
I suspect you are far more of a PG (or any other DBMS, for that matter)
user than I. Beyond these immediate "misapplications" of PG (in
deeply embedded systems), I have no long term needs for *any* DBMS.
To me, it's just another *tool*. Like writing something in LISP
that would be cumbersome to write in C, etc. I am far more
interested in the application domain than the tools used to
solve the problems presented therein.

Perhaps as a consequence of my last statement (above), I find
myself leaving more and more "thinking" to the tools. Years
(decades!) ago, I would write:
foo += (foo << 2);
instead of:
foo = foo * 5;
Now, I would never *obfuscate* my code with such a petty
optimization. I *know* the compiler is smarter than I am
at recognizing how best to optimize a given piece of code.
And, it can reevaluate its decisions each time I type "make"
instead of forcing me to reexamine each choice (which
variables should be in registers *now*, etc.).

I'll spend time considering overall solution *strategy*
and give careful consideration to the things that an
optimizer is unlikely to *ever* be able to sort out
(e.g., x[row][col] vs. x[col][row]) but those choices
yield *big* gains for the effort involved (whereas most
of the hundreds of optimizations that the compiler does
on my behalf would require significant effort for little
relative gain).

I figure there are very talented people working on the
NARROWLY DEFINED problems that these tools present. I.e.,
how to most efficiently allocate processor resources,
schedule instructions, etc. -- things that affect *all*
code. I will gladly defer to their expertise so that I
can concentrate on the more ambiguous issues presented in
the application itself -- things that *can't* benefit
from "canned solutions".

As I began this reply: you are probably "more" of a DBMS
user than I so your concerns may be a "bigger" part of your
conceptual workplace. For me, the DBMS is just a small
(though significant) part of a bigger solution. Using an
analogy that hits close to home (since I am traveling), I
am far more concerned over the flightworthiness of the aircraft
I board than the time it takes the reservationist to locate
my confirmed seat reservation!

--don

On Feb 7, 9:39*pm, Mladen Gogala <n... (AT) email (DOT) here.invalid> wrote:
you can use Ingres....