Re: Looks like merge join planning time is too big, 55 seconds

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Sergey Burladyan <eshkinkot(at)gmail(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Looks like merge join planning time is too big, 55 seconds
Date: 2013-08-02 03:19:15
Message-ID: 20130802031914.GE5669@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Sergey Burladyan escribió:
> I also find this trace for other query:
> explain select * from xview.user_items_v v where ( v.item_id = 132358330 );
>
> #0 0x00007ff766967620 in read () from /lib/libc.so.6
> #1 0x00007ff7689cfc25 in FileRead ()
> #2 0x00007ff7689ea2f6 in mdread ()
> #3 0x00007ff7689cc473 in ?? ()
> #4 0x00007ff7689ccf54 in ReadBufferExtended ()
> #5 0x00007ff7688050ca in index_fetch_heap ()
> #6 0x00007ff76880523e in index_getnext ()
> #7 0x00007ff768a63306 in ?? ()
> #8 0x00007ff768a67624 in ?? ()
> #9 0x00007ff768a67d9c in ?? ()
> #10 0x00007ff768a688fc in scalargtsel ()

It'd be useful to see what's in frames 7-9, but this might be related to
get_actual_variable_range(). I don't see anything else nearby that
would try to read portions of the table.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Vik Fearing 2013-08-02 07:37:44 Re: subselect requires offset 0 for good performance.
Previous Message Scott Marlowe 2013-08-02 01:22:25 Re: subselect requires offset 0 for good performance.