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-06 15:34:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Ioannis Anagnostopoulos <ioannis(at)anatec(dot)com> writes:
>         I think this is a pretty good plan and quite quick given the
>         size of the table (88Million rows at present). However in real
>         life the parameter where I search for msg_id is not an array of
>         3 ids but of 300.000 or more. It is then that the query forgets
>         the plan and goes to sequential scan. Is there any way around?

If you've got that many, any(array[....]) is a bad choice.  I'd try
putting the IDs into a VALUES(...) list, or even a temporary table, and
then writing the query as a join.  It is a serious mistake to think that
a seqscan is evil when you're dealing with joining that many rows, btw.
What you should probably be looking for is a hash join plan.

			regards, tom lane

In response to


pgsql-performance by date

Next:From: Midge BrownDate: 2012-08-06 17:43:13
Subject: Re: slow query, different plans
Previous:From: Ioannis AnagnostopoulosDate: 2012-08-06 15:24:57
Subject: Re: Sequential scan instead of index scan

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