- 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 ind
Brad Nicholson writes:
> On 10/27/2010 4:10 PM, Tom Lane wrote:
>> AFAICT from googling, AIX does have posix_fadvise, though maybe it
>> doesn't do anything useful ...
> If there is an easy way to check if it does do anything useful? If so,
> I can check it out.
If you don't see any performanc
On 10/27/2010 4:10 PM, Tom Lane wrote:
Greg Smith writes:
André Volpato wrote:
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.
AFAICT from googl
- 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 inde
Greg Smith writes:
> André Volpato wrote:
>> 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.
AFAICT from googling, AIX does have posix_fadvi
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
On 10-10-26 05:04 PM, André Volpato wrote:
- 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 t
- 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.
| > |> I´ve never seen this b
On 10-10-25 03:26 PM, André Volpato wrote:
| 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 resul
| 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.
| >
| > Here´s some background
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.
>
> Here´s some background info:
>
> AIX Box:
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.
Here´s some background info:
AIX Box:
PostgreSQL 8.4.4, AIX 5.3-9 64bits, SAN IBM DS3400, 8x450GB SAS 15K Ra
12 matches
Mail list logo
