UNSUBSCRIBE
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
del40.
>
> regards, tom lane
>
> ---(end of broadcast)---
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
>
--
taking
forever... and killed it after 30mins.
Thanks
shoaib
On Thu, 21 Apr 2005, John A Meinel wrote:
> Shoaib Burq (VPAC) wrote:
>
> >Just tried it with the following changes:
> >
> >shared_buffers = 10600
> >work_mem = 102400
> >enable_seqscan = false
&
ntAusClimate" on
"CurrentAusClimate" (cost=0.00..46.20 rows=11 width=14) (actual
time=0.007..0.009 rows=1 loops=13276368)
Index Cond: (("CurrentAusClimate"."ClimateId" =
"outer"."ClimateId") AND ("outer".&q
> 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)---
1055 99786 54 20
21 5
0 1 25820 9128 6345768 167468401 2868 3016 1049 98301 55 21
19 6
2 1 25820 8160 6345828 167557600 3079 3056 1050 93725 55 19
21 5
On Thu, 21 Apr 2005, Shoaib Burq (VPAC) wrote:
>
> here's explain sorry about the mess: I can a
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
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
