You may be comparing the values to Tom's suggestion to bump up work_mem. Take a look at the original posting (Total runtime: 777208.041 ms for the bitmap scan) -Steve "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: On Thu, May 18, 2006 at 12:53:16PM -0700, Stephen Byers wrote:> Yes, here a
On Thu, May 18, 2006 at 12:53:16PM -0700, Stephen Byers wrote:
> Yes, here are the runtimes for the repeated query.
> Total runtime: 748716.750 ms
> Total runtime: 749170.934 ms
> Total runtime: 744113.594 ms
> Total runtime: 746314.251 ms
> Total runtime: 742083.732 ms
With which options enable
Yes, here are the runtimes for the repeated query. Total runtime: 748716.750 msTotal runtime: 749170.934 msTotal runtime: 744113.594 msTotal runtime: 746314.251 msTotal runtime: 742083.732 ms Thanks, Steve"Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: On Thu, May 18, 2006 at 12:38:18PM -0700
On Thu, May 18, 2006 at 12:38:18PM -0700, Stephen Byers wrote:
> I repeated explain analyze on the query 5 times and it came up with the same
> plan.
Yes, but did it end up with the same runtime? That's the interesting part --
the plan will almost always be identical between explain analyze runs
I repeated explain analyze on the query 5 times and it came up with the same plan. You asked about index order and physical table order. In general the index order is indeed close to the same order as the physical table order. However, this query is likely an exception. The data is actually fro
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> What about the working set? Have you tried running the queries multiple times
> in a row to see if the results change? It might be that your initial bitmap
> scan puts all the relevant bits into cache, which will skew the results.
If the example
On Thu, May 18, 2006 at 09:41:23AM -0700, Stephen Byers wrote:
> Does the table perchance fit completely into memory, without
> effective_cache_size indicating that?
>
> Don't know the exact way to answer your question, but my initial instinct
> is "no way."
What about the working set? Have yo
"Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: It sounds like PostgreSQL badly overestimates the cost of the index scan.Does the table perchance fit completely into memory, withouteffective_cache_size indicating that? Don't know the exact way to answer your question, but my initial instinct is
You may also try PgFouine (http://pgfouine.projects.postgresql.org/)
for log analysis, I found it very useful in similar situation.
On 5/17/06, Ruben Rubio Rey <[EMAIL PROTECTED]> wrote:
Hi,
I have a web page, that executes several SQLs.
So, I would like to know witch one of those SQLs consum
On Thu, May 18, 2006 at 08:52:04AM -0700, Stephen Byers wrote:
> Could someone explain the results of the following?
It sounds like PostgreSQL badly overestimates the cost of the index scan.
Does the table perchance fit completely into memory, without
effective_cache_size indicating that?
> Also,
Could someone explain the results of the following? This is with postgres 8.1.2 on a database that was just vacuum-verbose-analyzed. I have packets_i4 index which I am expecting to be used with this query but as you can see, I have have to convince its usage by turning off other scans. The total
Title: RE: [PERFORM] Performance/Maintenance test result collection
Yes, regular versus full vacuum. Thanks for the comment but I was hoping to come to that conclusion on my own by observing the affects of the different vacuums.
My original question was guidance on collecting data for confirm
[EMAIL PROTECTED] wrote:
On 17 May 2006, at 16:21, Ruben Rubio Rey wrote:
I have a web page, that executes several SQLs.
So, I would like to know witch one of those SQLs consumes more CPU.
For example,
I have SQL1 that is executed in 1.2 secs and a SQL2 that is executed
in 200 ms.
But SQL
"Mikael Carneholm" <[EMAIL PROTECTED]> writes:
> Btw, check you logfile for hints regarding increasing max_fsm_pages, and
> consider increasing checkpoint_segments as well. You could also play
> with more aggressive bgwriter_* params to reduce the risk for long
> vacuum pauses.
Yeah, checkpoint_se
What filesystem are you using - ext2/etx3/xfs/jfs/...? Does the SCSI
controller have a battery backed cache? For ext3, mounting it with
data=writeback should give you quite a boost in write performance.
What benchmark tool are you using - is it by any chance BenchmarkSQL?
(since you mention that i
> > Could you give us some more infos about the box' performance while you
> > run the PG benchmark? A few minutes output of "vmstat 10" maybe? What
> > does "top" say?
>
> >
> Here, an extract from the vmstat 3 during the test, you can see that
> my problem is probably a very high disk usage (wr
On 18.05.2006, at 12:42 Uhr, Olivier Andreotti wrote:
I use prepared statements for all requests. Each transaction is about
5-45 requests.
This may lead to bad plans (at least with 8.0.3 this was the
case) ... I had the same problem a couple of months ago and I
switched from prepared state
Do you use prepared statements through JDBC with bound variables? If
yes, you might have problems with PostgreSQL not choosing optimal
plans because every statement is planned "generically" which may
force PostgreSQL not to use indexes.
i used prepared statements for the 3 databases.
> share
Hi Olivier,
First question I'd like to ask is: will this benchmark and its results
will be accessible on the net when you'll have finished ?
I'm interested about your benchmark and your results.
> I'm running a benchmark with theses 3 databases, and the first results
> are not very good for Post
That fsync off would make me very unhappy in a production environment not
that turning it on would help postgres, but ... one advantage of postgres is
its reliability under a "pull the plug" scenario, but this setting defeats that.
FWIW, Xeon has gotten quite negative reviews in these quar
2006/5/18, Chris Mair <[EMAIL PROTECTED]>:
Hello :)
Hello Chris
What version would PostgreSQL 8.1.4 be?
Hum, ok, it is the 8.1.3 version :)
Could you give us some more infos about the box' performance while you
run the PG benchmark? A few minutes output of "vmstat 10" maybe? What
does "
Hello :)
What version would PostgreSQL 8.1.4 be?
> I'm running a benchmark with theses 3 databases, and the first results
> are not very good for PostgreSQL.
Could you give us some more infos about the box' performance while you
run the PG benchmark? A few minutes output of "vmstat 10" maybe? Wh
Hi, Mario,
Mario Splivalo wrote:
> This helps also. I don't get sequential scans any more. I'd like a tip
> on how to set 'enable_nestloop = off' trough JDBC?
statement.execute("SET enable_nestloop TO off"); should do.
HTH,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Hello,
I'm running a benchmark with theses 3 databases, and the first results
are not very good for PostgreSQL.
PostgreSQL is 20% less performance than MySQL (InnoDB tables)
My benchmark uses the same server for theses 3 databases :
Dell Power edge - Xeon 2.8 Ghz - 2 Go Ram - 3 SCSI disks - Deb
* Jignesh K. Shah:
> * llseek is high which means you can obviously gain a bit with the
> right file system/files tuning by caching them right.
It might also make sense to switch from lseek-read/write to
pread/pwrite. It shouldn't be too hard to hack this into the virtual
file descriptor module.
1.451 ms = 1.451 milliseconds
1451.0 ms = 1.451 seconds ...
so 32.918 ms for a commit seems perhaps reasonable ?
Greg Williamson
DBA
GlobeXplorer LLC
-Original Message-
From: [EMAIL PROTECTED] on behalf of Zeugswetter Andreas DCP SD
Sent: Thu 5/11/2006 12:55 AM
To: Jim C. Nasby
26 matches
Mail list logo
