est with 89 MB/s writing and 110MB/s reading.
Can you give some hints, if this numbers seems to be reasonable?
kind regards
Janning
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On Thursday 24 June 2010 14:53:57 Matthew Wakeling wrote:
> On Thu, 24 Jun 2010, Janning wrote:
> > We have a 12 GB RAM machine with intel i7-975 and using
> > 3 disks "Seagate Barracuda 7200.11, ST31500341AS (1.5 GB)"
>
> Those discs are 1.5TB, not 1.5GB.
sorry,
thanks for your quick response, kenneth
On Thursday 24 June 2010 14:47:34 you wrote:
> On Thu, Jun 24, 2010 at 02:43:33PM +0200, Janning wrote:
> > Hi,
> >
> > at the moment we encounter some performance problems with our database
> > server.
> >
> > We hav
On Thursday 24 June 2010 15:16:05 Janning wrote:
> On Thursday 24 June 2010 14:53:57 Matthew Wakeling wrote:
> > On Thu, 24 Jun 2010, Janning wrote:
> > > We have a 12 GB RAM machine with intel i7-975 and using
> > > 3 disks "Seagate Barracuda 7200.11, ST3150034
experience apache in standard configuration can be the main bottleneck.
and teh combination of keepalive off, lingerd and mod_gzip is GREAT and i
didn't found much sites propagating a configuration like this.
kind regards,
janning
p.s: sorry for being slightly off topic and talking about apache b
d one will be much faster because of some or even all
data needed to answer the query is still in the shared buffers.
janning
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column&
it doesn't
> 2nd query doing perfect as you see.
postgres uses a seq scan if its faster. In your case postgres seems to know
that most of your rows have a date < 2004-01-01 and so doesn't need to
consult the index if it has to read every page anyway. seq scan
Am Montag, 11. Oktober 2004 22:49 schrieb Francisco Reyes:
> On Mon, 11 Oct 2004, Janning Vygen wrote:
> > postgres uses a seq scan if its faster. In your case postgres seems to
> > know that most of your rows have a date < 2004-01-01 and so doesn't need
> > to consul
re to start research?
My guess is that the update statement inside the rule doesnt really uses the
index on punktecache, but i dont know why and i dont know how to change it.
Any hint or help is is very appreciated.
kind regards
janning
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
