Shoaib Burq (VPAC) wrote:
OK ... so just to clearify... (and pardon my ignorance):
I need to increase the value of 'default_statistics_target' variable and
then run VACUUM ANALYZE, right? If so what should I choose for the
'default_statistics_target'?
BTW I only don't do any sub-selection on the V
> -Original Message-
> From: Shoaib Burq (VPAC) [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 26, 2005 9:31 AM
> To: Tom Lane
> Cc: John A Meinel; Russell Smith; Jeff;
> pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] two queries and dual cpu (perplex
OK ... so just to clearify... (and pardon my ignorance):
I need to increase the value of 'default_statistics_target' variable and
then run VACUUM ANALYZE, right? If so what should I choose for the
'default_statistics_target'?
BTW I only don't do any sub-selection on the View.
I have attached
John A Meinel <[EMAIL PROTECTED]> writes:
> Actually, you probably don't want enable_seqscan=off, you should try:
> SET enable_nestloop TO off.
> The problem is that it is estimating there will only be 44 rows, but in
> reality there are 13M rows. It almost definitely should be doing a
> seqscan wi
On Thu, Apr 21, 2005 at 08:24:15AM -0400, Jeff wrote:
>
> On Apr 21, 2005, at 7:49 AM, Shoaib Burq (VPAC) wrote:
>
> >Now I have not touch the $PGDATA/postgresql.conf (As I know very little
> >about memory tuning) Have run VACCUM & ANALYZE.
> >
> You should really, really bump up shared_buffers a
Shoaib Burq (VPAC) schrieb:
Hi everybody,
One of our clients was using SQL-Server and decided to switch to
PostgreSQL 8.0.1.
Hardware: Dual processor Intel(R) Xeon(TM) CPU 3.40GHz
OS: Enterprise Linux with 2.6.9-5 SMP kernel
Filesystem: ext3
SHMMAX: $ cat /proc/sys/kernel/shmmax
6442450944 <--- b
On Apr 21, 2005, at 11:33 PM, Shoaib Burq (VPAC) wrote:
BTW I guess should mention that I am doing the select count(*) on a
View.
A bit of a silly question...
but are you actually selecting all the rows from this query in
production or would it be more selective? ie select * from bigslowview
w
On Fri, 22 Apr 2005, Shoaib Burq (VPAC) wrote:
> Please see attached the output from explain analyse. This is with the
>
> shared_buffers = 10600
> work_mem = 102400
> enable_seqscan = true
>
> BTW I guess should mention that I am doing the select count(*) on a View.
>
> Ran the
Please see attached the output from explain analyse. This is with the
shared_buffers = 10600
work_mem = 102400
enable_seqscan = true
BTW I guess should mention that I am doing the select count(*) on a View.
Ran the Explain analyse with the nestedloop disabled but it was
Shoaib Burq (VPAC) wrote:
Just tried it with the following changes:
shared_buffers = 10600
work_mem = 102400
enable_seqscan = false
still no improvement
Ok here's the Plan with the enable_seqscan = false:
ausclimate=# explain ANALYZE select count(*) from "getfutureausclimate";
Actually, you proba
Just tried it with the following changes:
shared_buffers = 10600
work_mem = 102400
enable_seqscan = false
still no improvement
Ok here's the Plan with the enable_seqscan = false:
ausclimate=# explain ANALYZE select count(*) from "getfutureausclimate";
> Is this an IO intensive query? If running both in parellel results in
> 2x the run time and you have sufficient cpus it would (to me) indicate
> you don't have enough IO bandwidth to satisfy the query.
any tips on how to verify this?
---(end of broadcast)---
here are some i/o stats with the unchanged postgresql.conf. Gonna change
it now and have another go.
[EMAIL PROTECTED] MultiCPU_test]$ vmstat 10
procs ---memory-- ---swap-- -io --system--
cpu
r b swpd free buff cache si sobibo incs us s
On Thu, 21 Apr 2005 10:44 pm, Shoaib Burq (VPAC) wrote:
> -> Nested Loop (cost=2.19..1069345.29 rows=16 width=58) (actual
> time=135.390..366902.373 rows=13276368 loops=1)
> -> Nested Loop (cost=2.19..1067304.07 rows=44
> width=68) (actual time=107.627..186390.137 rows=
here's explain sorry about the mess: I can attach it as text-file if you
like.
ausclimate=# explain ANALYZE select count(*) from "getfutureausclimate";
QUERY PLAN
On Thu, 21 Apr 2005, Jeff wrote:
>
> On Apr 21, 2005, at 7:49 AM, Shoaib Burq (VPAC) wrote:
>
> > Now I have not touch the $PGDATA/postgresql.conf (As I know very little
> > about memory tuning) Have run VACCUM & ANALYZE.
> >
> You should really, really bump up shared_buffers and given you have 8G
On Apr 21, 2005, at 7:49 AM, Shoaib Burq (VPAC) wrote:
Now I have not touch the $PGDATA/postgresql.conf (As I know very little
about memory tuning) Have run VACCUM & ANALYZE.
You should really, really bump up shared_buffers and given you have 8GB
of ram this query would likely benefit from more wo
Hi everybody,
One of our clients was using SQL-Server and decided to switch to
PostgreSQL 8.0.1.
Hardware: Dual processor Intel(R) Xeon(TM) CPU 3.40GHz
OS: Enterprise Linux with 2.6.9-5 SMP kernel
Filesystem: ext3
SHMMAX: $ cat /proc/sys/kernel/shmmax
6442450944 <--- beleive that's ~6.5 GB, tot
18 matches
Mail list logo
