Re: [PERFORM] A Better External Sort?

Ron,

This thread is getting on my nerves. Your tone in some of the other
posts (as-well-as this one) is getting very annoying. Yes,
PostgreSQL's storage manager (like all other open source databases),
lacks many of the characteristics and enhancements of the commercial
databases. Unlike Oracle, Microsoft, etc., the PostgreSQL Global
Development Group doesn't have the tens of millions of dollars
required to pay hundreds of developers around the world for
round-the-clock development and R&D. Making sure that every little
tweak, on every system, is taken advantage of is expensive (in terms
of time) for an open source project where little ROI is gained.
Before you make a statement like, "I wanted to verify that pg's IO
rates were inferior to The Competition", think about how you'd write
your own RDBMS from scratch (in reality, not in theory).

As for your question regarding developer docs for the storage manager
and related components, read the READMEs and the code... just like
everyone else.

Rather than posting more assumptions and theory, please read through
the code and come back with actual suggestions.

-Jonah

2005/10/5, Ron Peacetree <rjpeace(at)earthlink(dot)net>:
> First I wanted to verify that pg's IO rates were inferior to The Competition.
> Now there's at least an indication that someone else has solved similar
> problems. Existence proofs make some things easier ;-)
>
> Is there any detailed programmer level architectual doc set for pg? I know
> "the best doc is the code", but the code in isolation is often the Slow Path to
> understanding with systems as complex as a DBMS IO layer.
>
> Ron
>
>
> -----Original Message-----
> From: "Joshua D. Drake" <jd(at)commandprompt(dot)com>
> Sent: Oct 5, 2005 1:18 PM
> Subject: Re: [HACKERS] [PERFORM] A Better External Sort?
>
>
> The source is freely available for your perusal. Please feel free to
> point us in specific directions in the code where you may see some
> benefit. I am positive all of us that can, would put resources into
> fixing the issue had we a specific direction to attack.
>
> Sincerely,
>
> Joshua D. Drake
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>

--
Respectfully,

Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
http://www.enterprisedb.com/