Re: SELECT's take a long time compared to other DBMS

A long time ago, in a galaxy far, far away, "Relaxin" <noname(at)spam(dot)com> wrote:
>> Have you changed any of the settings yet in postgresql.conf,
>> specifically the shared_buffers setting?
>
> fsync = false
> tcpip_socket = true
> shared_buffers = 128

Change fsync to true (you want your data to survive, right?) and
increase shared buffers to something that represents ~10% of your
system memory, in blocks of 8K.

So, if you have 512MB of RAM, then the total blocks is 65536, and it
would likely be reasonable to increase shared_buffers to 1/10 of that,
or about 6500.

What is the value of effective_cache_size? That should probably be
increased a whole lot, too. If you are mainly just running the
database on your system, then it would be reasonable to set it to most
of memory, or
(* 1/2 (/ (* 512 1024 1024) 8192))
32768.

None of this is likely to substantially change the result of that one
query, however, and it seems quite likely that it is because
PostgreSQL is honestly returning the whole result set of ~100K rows at
once, whereas the other DBMSes are probably using cursors to return
only the few rows of the result that you actually looked at.
--
"cbbrowne","@","cbbrowne.com"
http://www3.sympatico.ca/cbbrowne/linuxdistributions.html
Rules of the Evil Overlord #14. "The hero is not entitled to a last
kiss, a last cigarette, or any other form of last request."
<http://www.eviloverlord.com/>