Ron,

On 9/30/05 1:20 PM, "Ron Peacetree" <rjpeace@earthlink.net> 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

On R, 2005-09-30 at 13:38 -0700, Luke Lonergan wrote:

>
> 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.

Is this < 1/2 of MySQL with WAL on different spindle and/or WAL
disabled ?

--
Hannu Krosing <hannu@skype.net>


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend