From: | André Volpato <andre(dot)volpato(at)ecomtecnologia(dot)com(dot)br> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: AIX slow buffer reads |
Date: | 2010-10-28 12:33:07 |
Message-ID: | 647835811.10922.1288269187954.JavaMail.root@zimbra01a |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
----- Mensagem original -----
| André Volpato wrote:
| > |
| > | If it is being spent in the bitmap index scan, try setting
| > | effective_io_concurrency to 0 for Linux, and see what effect that
| > | has.
| >
| > I disabled effective_io_concurrency at AIX but it made no changes on
| > bitmap index times.
| >
|
| Brad's point is that it probably doesn't do anything at all on AIX,
| and
| is already disabled accordingly. But on Linux, it is doing something,
| and that might be contributing to why it's executing so much better on
| that platform. If you disable that parameter on your Debian box, that
| should give you an idea whether that particular speed-up is a major
| component to the difference you're seeing or not.
Here´s new explains based on Debian box:
(1) effective_io_concurrency = 5
# /etc/init.d/postgresql stop
# echo 3 > /proc/sys/vm/drop_caches
# /etc/init.d/postgresql start
http://explain.depesz.com/s/br
(2) effective_io_concurrency = 0
# /etc/init.d/postgresql stop
# echo 3 > /proc/sys/vm/drop_caches
# /etc/init.d/postgresql start
http://explain.depesz.com/s/3A0
BitmapAnd really gets improved a little bit in (1), but Bitmap index scans got a lot worse.
| --
| Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
| PostgreSQL Training, Services and Support www.2ndQuadrant.us
| "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
[]´s, Andre Volpato
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2010-10-28 13:13:22 | Re: Postgres insert performance and storage requirement compared to Oracle |
Previous Message | Pierre C | 2010-10-28 09:33:16 | Re: Select count(*), the sequel |