Ron, On 9/30/05 1:20 PM, "Ron Peacetree" <[EMAIL PROTECTED]> wrote:
> That 11MBps was your =bulk load= speed. If just loading a table > is this slow, then there are issues with basic physical IO, not just > IO during sort operations. Bulk loading speed is irrelevant here - that is dominated by parsing, which we have covered copiously (har har) previously and have sped up by 500%, which still makes Postgres < 1/2 the loading speed of MySQL. > As I said, the obvious candidates are inefficient physical layout > and/or flawed IO code. Yes. > Until the basic IO issues are addressed, we could replace the > present sorting code with infinitely fast sorting code and we'd > still be scrod performance wise. Postgres' I/O path has many problems that must be micro-optimized away. Too small of an operand size compared to disk caches, memory, etc etc are the common problem. Another is lack of micro-parallelism (loops) with long enough runs to let modern processors pipeline and superscale. The net problem here is that a simple "select blah from blee order by(blah.a);" runs at 1/100 of the sequential scan rate. - Luke ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
