Re: On what we want to support: travel? - Mailing list pgsql-advocacy

On 11/8/06, Robert Treat <xzilla@users.sourceforge.net> wrote:
> Really?  Your first argument was that PostgreSQL would not be accepted because
> it was not known to them.  Well, presenting at conferences get this project
> exposure, both to developers and to executives, depending on the conference.
> Imagine that the largest software conference in Brazil asks the project if
> someone cancome to their country to give a keynote speech.  Do you really
> want to turn down that exposure?  Do you want to not have a booth at a
> conference like the recent one in Germany where there are 50,000 attendees,
> and you know they are going to go to booths for a half dozen other database
> groups?

I didn't write anywhere that I don't want to have a booth. Booth will certainly
attract new people to PostgreSQL and is certainly helpful to the community.
My point was rather about situation where some other OS DB is used, and
there's not much traction towards PostgreSQL.  Booths prove that PostgreSQL
is used and developed, but... well, some other OS DB also is (hence, no
traction).  Having PostgreSQL in different league would help use both of
these products at things they are best at.  And I feel, TPC gives here
more leverage.

This is a specific case.  I don't intend to prove that it is generally better.
I think expanding userbase is very important, and good to have PostgreSQL's
presence as wide as possible.  I only wanted to state, that I know
environments where convention-presence-or-not, other DB is "good enough",
and some other forms of presence might be more helpful.

> > Having TPC membership
> > and benchmarks gives leverage (buzzwordish, but still) for convincing
> > sceptics into at least fully testing PostgreSQL. The "TPC-like" tests
> > are useless in such "political" discussions.
> Does it?  Have you looked at a TPC benchmark, or the published results? There
> is *no way* we can top the performance metrics that are put out by folks like
> Oracle if for no other reason than the systems they run the test on are
> completely unrealistic.  And we cannot run our own TPC benchmarks with other
> database software on a standardized hardware because their software licenses
> will not allow it.  And even if we could of course people would dismiss it as
> biased testing.

There is a race called Dakar-Rally.  It involves cars racing in harsh
environment (sand, rocks, mud, etc.).  From time to time some
car manufacturer will put there one of their "standard model" of
a car, to proove their endurance, and to use the race as a testing
ground for it.  Why do they do that?  They have no chance of
winning, and non-zero probability that the race will be too hard
for a "regular" car.  I see a parallel here.

> Except that this ignores all of the market research that open source is
> traditionally implemented in companies from the ground up rather than from
> the top down.

Think of not a startup company which is doing a research right now,
but rather a company that has gone through such research some
time ago and made its choices.  How would you argument making
fundamental change in DB backend now?  Sun's support helps here,
both to down and ground up.

> If we were going to do that, yes, it would make sense to do it that way, but I
> think the current feeling is that people should be kept as local as possible;
> ie. flying someone over from the U.S. to Europe on our own dime makes little
> sense when there are a lot of solid contributors in Europe already.

Totally agree.  But since earlier examples involved flying Asia, Middle
East and Europe, I just couldn't resist suggesting it.

> On a side note, this discussion seems to be turning into a TPC vs. Speakers
> debate, which is unfortunate, as there are certainly other items that should
> be in a discussion of things to spend money on, like software certifications
> and standards processes, which so far have pretty much been ignored.

It was not my intention.  My point was that TPC might not be necesarilly
worthless.

   Regards,
       Dawid