, and I can ensure AIX isn´t
touching the disks anymore.
I´ve never seen this behaviour before. I heard about Direct I/O and I was
thinking about givng it a shot.
Any ideas?
1 - http://explain.depesz.com/s/5oz
[]´s, André Volpato
--
Sent via pgsql-performance mailing list (pgsql-performance
| On Mon, Oct 25, 2010 at 2:21 PM, André Volpato
| wrote:
| > Hi all,
| >
| > We are tuning a PostgreSQL box with AIX 5.3 and got stucked in a
| > very odd situation.
| > When a query got ran for the second time, the system seems to
| > deliver the results to slow.
| >
| >
- Mensagem original -
| On 10-10-25 03:26 PM, André Volpato wrote:
| > | On Mon, Oct 25, 2010 at 2:21 PM, André Volpato
| > | wrote:
(...)
| > |> These times keep repeating after the second run, and I can
| > |> ensure AIX isn´t touching the disks anymore.
| > |&g
- 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 cha
- 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 cha
Folks,
In a fresh Pg8.3.3 box, we created a 3-stripe RAID0 array.
The write speed is about 180MB/s, as shown by dd :
# dd if=/dev/zero of=/postgres/base/teste2 bs=1024 count=500
500+0 records in
500+0 records out
512000 bytes (5,1 GB) copied, 28,035 seconds, 183 MB/s
BTW, /postg
David Wilson escreveu:
On Wed, Aug 20, 2008 at 2:30 PM, André Volpato
<[EMAIL PROTECTED]> wrote:
The CPU is 100% used since a few hours ago. Can anyone tell why?
Sounds like you've just got a CPU bound query. The data may even all
be in cache.
Some information on da
André Volpato escreveu:
David Wilson escreveu:
On Wed, Aug 20, 2008 at 2:30 PM, André Volpato
<[EMAIL PROTECTED]> wrote:
The CPU is 100% used since a few hours ago. Can anyone tell why?
Sounds like you've just got a CPU bound query. The data may even all
be in c
Tom Lane escreveu:
=?ISO-8859-1?Q?Andr=E9_Volpato?= <[EMAIL PROTECTED]> writes:
Explain output:
HashAggregate (cost=19826.23..19826.96 rows=73 width=160) (actual
time=11826.754..11826.754 rows=0 loops=1)
-> Subquery Scan b2 (cost=19167.71..19817.21 rows=722 width=160)
(actual time=11
Tom Lane escreveu:
We are guessing that a dual core 3.0GHz will beat up a quad core 2.2,
at least in this environmnent with less than 4 concurrent queryes.
The most you could hope for from that is less than a 50% speedup. I'd
suggest investing some tuning effort first. Some rethinking of your
Gregory Stark escreveu:
André Volpato <[EMAIL PROTECTED]> writes:
I think we almost reached the tuning limit, without changing the schema.
It's hard to tell from the plan you posted (and with only a brief look) but it
looks to me like your query with that
per now is change the application to use "BETWEEN" olny
when year and month are not the same.
How can condition 1 be so badly estimated?
--
[]´s,
André Volpato
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
ht
André Volpato escreveu:
(...)
(Postgres 8.3.6, Debian Linux 2.6.18-6-amd64)
(...)
Condition 1:
# select fat_referencia from bds_contratacao_fatura where
fat_referencia BETWEEN 200908 AND 200908;
Index Scan using ibds_contratacao_fatura1 on bds_contratacao_fatura
(cost=0.00..5.64 rows=1
13 matches
Mail list logo
