Re: Anyone working on better transaction locking?

"Andrew Sullivan" <andrew(at)libertyrms(dot)info> wrote in message
news:20030409170926(dot)GH2255(at)libertyrms(dot)info(dot)(dot)(dot)
> On Wed, Apr 09, 2003 at 05:41:06AM +0000, Ron Peacetree wrote:
> Nonsense. You explicitly made the MVCC comparison with Oracle, and
> are asking for a "better" locking mechanism without providing any
> evidence that PostgreSQL's is bad.
>
Just because someone else's is "better" does not mean PostgreSQL's is
"bad", and I've never said such. As I've said, I'll get back to Tom
and the list on this.

> > compares PostgreSQL to the performance leaders within this domain
> > since I'll have to justify my decisions to my bosses based on such
> > comparisons. If you think that is unrealistic, then I wish I
> > worked where you do.
>
> Where I work, we test our systems to performance targets having to
> do with what we use the database for. Generic database benchmarks
> are not something I have a great deal of faith in. I repeat my
> assertion that, if you have specific areas of concern and the like,
> and they're not on the TODO (or in the FAQ), then people would be
> likely to be interested; although they'll likely be more interested
if the
> specifics are not a lot of hand-wavy talk about PostgreSQL not doing
> something the right way.
>
There's nothing "hand wavy"about this unless you think anything except
test cases is "hand wavy". In that case, you're right. I don't have
the time or resources to provide exhaustive tests between each DB for
each of the issues we are discussing. If I did, I'd be publishing a
=very= lucrative newsletter for IT decision makers. Also, there are
other
valid ways to analyze issues than just application level test cases.
In fact, there are some =better= ways, depending on the issue being
discussed.

> > treating PostgreSQL as a religion and not a SW product that must
> > compete against every other DB solution in the real world in order
> > to be relevant or even survive.
>
> Actually, given that we are dependent on PostgreSQL's performance
> and stability for the whole of the company's revenue, I am pretty
> certain that I have as much "real world" experience of PostgreSQL
> use as anyone else.
>
Your experience was not questioned, and there were "if" clauses at the
beginning of my comments that you seem to be ignoring. I'm not here
to waste my or anyone else's time on flames. We've all got work to
do.

> > Please see my posts with regards to ...
>
> I think your other posts were similar to the one which started this
> thread: full of mighty big pronouncements which turned out to depend
> on a bunch of not-so-tenable assumptions.
>
Hmmm. Well, I don't think of algorithm analysis by the likes of
Knuth, Sedgewick, Gonnet, and Baeza-Yates as being "not so tenable
assumptions", but YMMV. As for "mighty pronouncements", that also
seems a bit misleading since we are talking about quantifiable
programming and computer science issues, not unquantifiable things
like politics.

> I'm sorry to be so cranky about this, but I get tired of having to
> defend one of my employer's core technologies from accusations based
> on half-truths and "everybody knows" assumptions. For instance,
>
Again, "accusations" is a bit strong. I thought the discussion was
about the technical merits and costs of various features and various
ways to implement them, particularly when this product must compete
for installed base with other solutions. Being coldly realistic about
what a product's strengths and weaknesses are is, again, just good
business. Sun Tzu's comment about knowing the enemy and yourself
seems appropriate here...

> > I'll mention thread support in passing,
>
> there's actually a FAQ item about thread support, because in the
> opinion of those who have looked at it, the cost is just not worth
> the benefit. If you have evidence to the contrary (specific
> evidence, please, for this application), and have already read all
the
> previous discussion of the topic, perhaps people would be interested
in
> opening that debate again (though I have my doubts).
>
Zeus had a performance ceiling roughly 3x that of Apache when Zeus
supported threading as well as pre-forking and Apache only supported
pre forking. The Apache folks now support both. DB2, Oracle, and SQL
Server all use threads. Etc, etc.

That's an awful lot of very bright programmers and some serious $$
voting that threads are worth it. Given all that, if PostgreSQL
specific
thread support is =not= showing itself to be a win that's an
unexpected
enough outcome that we should be asking hard questions as to why not.

At their core, threads are a context switching efficiency tweak.
Since DB's switch context a lot under many circumstances, threads
should be a win under such circumstances. At the least, it should be
helpful in situations where we have multiple CPUs to split query
execution between.

M$'s first implementation of threads was so "heavy" that it didn't
help them (until they actually implemented real threads and called
them "strings"), but that was not due to the inefficacy of the
concept, but rather M$'s implementation and the system environment
within which that implementation was being used. Perhaps something
similar is going on here?

Certainly it's =possible= that threads have nothing to offer
PostgreSQL, but IMHO it's not =probable=. Just another thing for me
to add to my TODO heap for looking at...