On Thu, Feb 21, 2013 at 8:57 AM, Carlo Stonebanks <
stonec.regis...@sympatico.ca> wrote:
> (Sorry moderators for any double posts, I keep making subscription errors.
> Hopefully this one gets through)
>
> Hi speed freaks,
>
> Can anyone tell me why the bitmap heap scan takes so long to start for t
(Sorry moderators for any double posts, I keep making subscription errors.
Hopefully this one gets through)
Hi speed freaks,
Can anyone tell me why the bitmap heap scan takes so long to start for this
query? (SQL and EXPLAIN ANALYZE follows).
The big culprit in this appears to be:
-> Bitmap In
On Thu, Feb 21, 2013 at 1:59 AM, Mark Smith wrote:
> Software: SLES 11 SP2 3.0.58-0.6.2-default x86_64, PostgreSQL 9.0.4.
[skipped]
> Problem: We have been running PostgreSQL 9.0.4 on SLES11 SP1, last kernel in
> use was 2.6.32-43-0.4, performance has always been great. Since updating
> from SLE
There's another thread in the list started by Josh Berkus about poor
performance with a similar kernel. I'd look that thread up and see if
you and he have enough in common to work together on this.
On Thu, Feb 21, 2013 at 2:59 AM, Mark Smith wrote:
> Hardware: IBM X3650 M3 (2 x Xeon X5680 6C 3.3
Hello Mark,
if i was you i would start with making basic benchmarks regarding IO
performance (bonnie++ maybe?) and i would check my sysctl.conf. your
parameters look ok to me.
when these delays occur have you noticed whats causing it ? An output of
vmstat when the delays are happening would also he
Hardware: IBM X3650 M3 (2 x Xeon X5680 6C 3.33GHz), 96GB RAM. IBM X3524
with RAID 10 ext4 (noatime,nodiratime,data=writeback,barrier=0) volumes for
pg_xlog / data / indexes.
Software: SLES 11 SP2 3.0.58-0.6.2-default x86_64, PostgreSQL 9.0.4.
max_connections = 1500
shared_buffers = 16GB
work_mem =
