Hi Luke,
I forgot about that article, thanks for that link. That's indeed a nice
overview of (in august) recent controllers. The Areca 1280 in that test
(and the results I linked to earlier) is a pre-production model, so it
might actually perform even better than in that test.
We've been
On Wed, 2006-11-22 at 11:17 +0100, Markus Schaber wrote:
PostgreSQL 8.1 (and, back then, 7.4) have the tendency to underestimate
the costs of sort operations, compared to index scans.
The Backend allocates gigs of memory (we've set sort_mem to 1 gig), and
then starts spilling out more Gigs
Greg Smith wrote:
On Mon, 13 Nov 2006, Guy Thornley wrote:
I've yet to find a drive that lies about write completion. The problem
is that the drives boot-up default is write-caching enabled (or perhaps
the system BIOS sets it that way). If you turn an IDE disks write cache
off
Greg Smith [EMAIL PROTECTED] writes:
The results I get now look fishy.
There are at least two things wrong with this program:
* It does not respect the alignment requirement for O_DIRECT buffers
(reportedly either 512 or 4096 bytes depending on filesystem).
* It does not check for errors (if
On Thu, 23 Nov 2006, Tom Lane wrote:
* It does not check for errors (if it had, you might have realized the
other problem).
All the test_fsync code needs to check for errors better; there have been
multiple occasions where I've run that with quesiontable input and it
didn't complain, it
On Tue, 2006-11-21 at 21:43 -0200, Carlos H. Reimer wrote:
Hi,
We have an application that is mission critical, normally very fast,
but when an I/O or CPU bound transaction appears, the mission critical
application suffers. Is there a way go give some kind of priority to
this kind of
Hi all,
I have a postgres installation thats running under 70-80% CPU usage
while
an MSSQL7 installation did 'roughly' the same thing with 1-2% CPU load.
Here's the scenario,
300 queries/second
Server: Postgres 8.1.4 on win2k server
CPU: Dual Xeon 3.6 Ghz,
Memory: 4GB RAM
Disks: 3 x
Gopal wrote:
Functions : Simple coordinate reprojection and intersection query +
inner join of table1 and table2.
I think I have all the right indexes defined and indeed the performance
for queries under low loads is fast.
Can you do a EXPLAIN ANALYZE on your queries, and send the results
Greg Smith wrote:
On Thu, 23 Nov 2006, Tom Lane wrote:
* It does not check for errors (if it had, you might have realized the
other problem).
All the test_fsync code needs to check for errors better; there have been
multiple occasions where I've run that with quesiontable input and it
