Re: Sequential scan instead of index scan - Mailing list pgsql-performance

From Tom Lane
Subject Re: Sequential scan instead of index scan
Date
Msg-id 5168.1344309207@sss.pgh.pa.us
Whole thread Raw
In response to Re: Sequential scan instead of index scan  (Ioannis Anagnostopoulos <ioannis@anatec.com>)
Responses Re: Sequential scan instead of index scan
List pgsql-performance
Ioannis Anagnostopoulos <ioannis@anatec.com> writes:
> On 06/08/2012 16:34, Tom Lane wrote:
>> What you should probably be looking for is a hash join plan.

> ...
> Which is a Merge join and not a hash. Any ideas how to make it a hash join?

You might need to ANALYZE the temp table, if you didn't already.  Also
it might be that you need to increase work_mem enough to fit the temp
table into memory.

Another thing that's bothering me is that the rowcount estimates are so
far off, particularly this one:

> "              ->  Index Scan using
> idx_ship_a_pos_messages_wk0_date_trunc on ship_a_pos_messages_wk0
> ship_pos_messages  (cost=0.00..1109877.86 rows=99313 width=128) (actual
> time=0.029..435784.376 rows=18499560 loops=1)"
> "                    Index Cond: (date_trunc('day'::text, msg_date_rec)
> = '2012-08-01 00:00:00'::timestamp without time zone)"
> "                    Filter: (date_part('day'::text, msg_date_rec) =
> 1::double precision)"

Offhand I'd have thought that ANALYZE would gather stats on the
date_trunc expression (because it is indexed) and then you should get
something reasonably accurate for a comparison to a constant.
"Reasonably accurate" meaning "not off by two orders of magnitude".
Practically all of your runtime is going into this one indexscan,
and TBH it seems likely you'd be better off with a seqscan there.

            regards, tom lane

pgsql-performance by date:

Previous
From: Ioannis Anagnostopoulos
Date:
Subject: Re: Sequential scan instead of index scan
Next
From: Stefan Keller
Date:
Subject: Slow query: Select all buildings that have >1 pharmacies and >1 schools within 1000m