Re: hash aggregation - Mailing list pgsql-performance

From Sergey Konoplev
Subject Re: hash aggregation
Date
Msg-id CAL_0b1tap1pSQ78t482ynYN_2yBqpYQnmJAXNC3zS023+=Xqqg@mail.gmail.com
Whole thread Raw
In response to Re: hash aggregation  (Korisk <Korisk@yandex.ru>)
Responses Re: hash aggregation  (Korisk <Korisk@yandex.ru>)
List pgsql-performance
On Thu, Oct 11, 2012 at 8:15 AM, Korisk <Korisk@yandex.ru> wrote:
> What's your seq_page_cost and random_page_cost?
> hashes=# SELECT name, setting, reset_val FROM pg_settings WHERE setting <> reset_val;
>           name           |    setting     | reset_val
> -------------------------+----------------+-----------
>  archive_command         | (disabled)     |
>  enable_bitmapscan       | off            | on
>  enable_indexscan        | off            | on
>  enable_seqscan          | off            | on
>  log_file_mode           | 0600           | 384
>  random_page_cost        | 0.1            | 4
>  seq_page_cost           | 0.1            | 1
>  transaction_isolation   | read committed | default
>  unix_socket_permissions | 0777           | 511

Could you please try to set *_page_cost to 1 and then EXPLAIN ANALYZE it again?

>    ->  Index Only Scan Backward using hashcheck_name_idx on public.hashcheck
>  (cost=10000000000.00..10000398674.92 rows=25986792 width=32)
>  (actual time=0.104..3785.767 rows=25990002 loops=1)

I am just guessing but it might probably be some kind of a precision
bug, and I would like to check this.

> (9 rows)
>
> Postgresql 9.2.1 was configured and built with default settings.
>
> Thank you.



--
Sergey Konoplev

a database and software architect
http://www.linkedin.com/in/grayhemp

Jabber: gray.ru@gmail.com Skype: gray-hemp Phone: +14158679984


pgsql-performance by date:

Previous
From: Korisk
Date:
Subject: Re: hash aggregation
Next
From: Josh Berkus
Date:
Subject: Re: shared_buffers/effective_cache_size on 96GB server