Re: Unexpected sequential scan on an indexed column

From: Eddy Escardo-Raffo <eescardo(at)kikini(dot)com>
To: Kenneth Marshall <ktm(at)rice(dot)edu>
Cc: Dave Crooke <dcrooke(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Unexpected sequential scan on an indexed column
Date: 2009-11-16 21:51:06
Message-ID: 4eaa4a5e0911161351j7e939327g7346bf6d36086908@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

This is incredibly helpful, Kenneth. I didn't know about the SETOF syntax at
all. This could help minimize the amount of refactoring I need to do.

Thanks!
Eddy

On Mon, Nov 16, 2009 at 12:55 PM, Kenneth Marshall <ktm(at)rice(dot)edu> wrote:

> On Mon, Nov 16, 2009 at 12:45:46PM -0800, Eddy Escardo-Raffo wrote:
> > Yeah this kind of thing would probably work. Doing this in java with
> > separate queries would be easy to code but require multiple round trips.
> > Doing it as a stored procedure would be nicer but I'd have to think a
> little
> > more about how to refactor the java code around the query to make this
> > happen. Thanks for the suggestion.
> >
> > Eddy
> >
>
> Hi Eddy,
>
> Here is a lookup wrapper that is used in DSPAM to work around
> a similar problem. Maybe you can use it as a template for your
> function:
>
> create function lookup_tokens(integer,bigint[])
> returns setof dspam_token_data
> language plpgsql stable
> as '
> declare
> v_rec record;
> begin
> for v_rec in select * from dspam_token_data
> where uid=$1
> and token in (select $2[i]
> from generate_series(array_lower($2,1),array_upper($2,1)) s(i))
> loop
> return next v_rec;
> end loop;
> return;
> end;';
>
> Regards,
> Ken
>
> > On Mon, Nov 16, 2009 at 9:44 AM, Dave Crooke <dcrooke(at)gmail(dot)com> wrote:
> >
> > > Hi Eddy
> > >
> > > Perhaps a slightly naive suggestion .... have you considered
> > > converting the query to a small stored procedure ('function' in
> > > Postgres speak)? You can pull the location values, and then iterate
> > > over a query like this:
> > >
> > > select userid from users where location=:x
> > >
> > > which is more-or-less guaranteed to use the index.
> > >
> > >
> > > I had a somewhat similar situation recently, where I was passing in a
> > > list of id's (from outwith Postgres) and it would on occasion avoid
> > > the index in favour of a full table scan .... I changed this to
> > > iterate over the id's with separate queries (in Java, but using a
> > > function will achieve the same thing) and went from one 5 minute query
> > > doing full table scan to a handful of queries doing sub-millisecond
> > > direct index lookups.
> > >
> > > Cheers
> > > Dave
> > >
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Dave Crooke 2009-11-16 21:52:08 Re: Unexpected sequential scan on an indexed column
Previous Message Alvaro Herrera 2009-11-16 21:25:54 Re: Is Diskeeper Automatic Mode safe?