Re: Set of related slow queries

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: John Williams <jwilliams(at)42nddesign(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Set of related slow queries
Date: 2011-06-08 09:20:46
Message-ID: 4DEF3EEE.1080203@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 8/06/2011 10:58 AM, John Williams wrote:

> -> Bitmap Heap Scan on logparser_entry
> (cost=4119.06..21520.55 rows=68787 width=8) (actual
> time=107.032..444.864 rows=16168 loops=1)
> Recheck Cond: ((event_type)::text = ANY
> ('{Attack,"DoT Tick","Critical Attack"}'::text[]))
> Filter: ((((target_relation)::text<> ALL
> ('{Other,N/A}'::text[])) OR (NOT (target_relation IS NOT NULL))) AND
> (log_id = 2))
> -> Bitmap Index Scan on
> logparser_entry_event_type_like (cost=0.00..4101.86 rows=217733
> width=0) (actual time=46.392..46.392 rows=237151 loops=1)
> Index Cond: ((event_type)::text = ANY
> ('{Attack,"DoT Tick","Critical Attack"}'::text[]))
> -> Hash (cost=196.49..196.49 rows=9749 width=23)
> (actual time=19.606..19.606 rows=9749 loops=1)

Thanks for including explain analyze output.

Is there any chance you can pop the full explains (not just excerpts) in
here:

http://explain.depesz.com/

?

Big query plans tend to get mangled into unreadable garbage by mail
clients, unfortunately.

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message anthony.shipman 2011-06-08 09:36:31 Re: strange query plan with LIMIT
Previous Message Pavel Stehule 2011-06-08 08:39:48 Re: strange query plan with LIMIT