eckout (which
we'll call 8.3dev). I'll let you guys (or at least Tom) know how they
compare in our benchmark.
Best regards,
Arjen
On 18-5-2007 15:12 Alvaro Herrera wrote:
Tom Lane wrote:
Arjen van der Meijden told me that according to the tweakers.net
benchmark, HEAD is noticeably
On 31-7-2007 5:07 Alvaro Herrera wrote:
Arjen van der Meijden wrote:
Afaik Tom hadn't finished his patch when I was testing things, so I don't
know. But we're in the process of benchmarking a new system (dual quad-core
Xeon) and we'll have a look at how it performs in th
For a more accurate view of the time used, use the \timing switch in psql.
That leaves out the overhead for forking and loading psql, connecting to
the database and such things.
I think, that it would be even nicer if postgresql automatically choose
to replace the count(*)-with-no-where with som
On 16-6-2006 17:18, Robert Lor wrote:
I think this system is well suited for PG scalability testing, among
others. We did an informal test using an internal OLTP benchmark and
noticed that PG can scale to around 8 CPUs. Would be really cool if all
32 virtual CPUs can be utilized!!!
I can al
On 17-6-2006 1:24, Josh Berkus wrote:
Arjen,
I can already confirm very good scalability (with our workload) on
postgresql on that machine. We've been testing a 32thread/16G-version
and it shows near-linear scaling when enabling 1, 2, 4, 6 and 8 cores
(with all four threads enabled).
Keen.
On 22-6-2006 15:03, David Roussel wrote:
Sureky the 'perfect' line ought to be linear? If the performance was
perfectly linear, then the 'pages generated' ought to be G times the
number (virtual) processors, where G is the gradient of the graph. In
such a case the graph will go through the or
