Skip site navigation (1) Skip section navigation (2)

Re: Sequential scan instead of index scan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ioannis Anagnostopoulos <ioannis(at)anatec(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Sequential scan instead of index scan
Date: 2012-08-07 03:13:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Ioannis Anagnostopoulos <ioannis(at)anatec(dot)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

In response to


pgsql-performance by date

Next:From: Stefan KellerDate: 2012-08-07 12:01:30
Subject: Slow query: Select all buildings that have >1 pharmacies and >1 schools within 1000m
Previous:From: Ioannis AnagnostopoulosDate: 2012-08-06 22:04:10
Subject: Re: Sequential scan instead of index scan

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group