Re: 57 minute SELECT

Поиск
Список
Период
Сортировка
От Claudio Freire
Тема Re: 57 minute SELECT
Дата
Msg-id CAGTBQpbMrJCTTicpGwfRRaHQ5haitdeqA9hCSpBiTFALYZVoMg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 57 minute SELECT  (Samuel Stearns <sstearns@staff.iinet.net.au>)
Ответы Re: 57 minute SELECT  (Samuel Stearns <sstearns@staff.iinet.net.au>)
Re: 57 minute SELECT  (Samuel Stearns <sstearns@staff.iinet.net.au>)
Список pgsql-performance
On Wed, Oct 2, 2013 at 10:17 PM, Samuel Stearns
<sstearns@staff.iinet.net.au> wrote:
> The last part, the EXPLAIN, is too big to send.  Is there an alternative way
> I can get it too you, other than chopping it up and sending in multiple
> parts?


Try explain.depesz.com


On Wed, Oct 2, 2013 at 10:30 PM, Samuel Stearns
<sstearns@staff.iinet.net.au> wrote:
>
> EXPLAIN:
>
> QUERY PLAN
>
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  Hash Join  (cost=408.53..1962721.39 rows=98068 width=126) (actual time=30121.265..3419306.752 rows=1929714 loops=1)
>    Hash Cond: (public.syslog_master.ip = public.devices.ip)

So your query is returning 2M rows.

I think you should try lowering work_mem. 512M seems oversized for a
query this complex on a system with 1G. You may be thrashing the OS
cache.

Also, you seem to have a problem with constraint exclusion. Some of
those bitmap heap scans aren't necessary, and the planner should know
it. Are you missing the corresponding CHECK constraints on datetime?


В списке pgsql-performance по дате отправления:

Предыдущее
От: Samuel Stearns
Дата:
Сообщение: Re: 57 minute SELECT
Следующее
От: Samuel Stearns
Дата:
Сообщение: Re: 57 minute SELECT