Re: Problem: query becomes slow when calling a fast user defined function.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dan Libby <dan(at)libby(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Problem: query becomes slow when calling a fast user defined function.
Date: 2006-06-06 02:43:02
Message-ID: 9625.1149561782@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Dan Libby <dan(at)libby(dot)com> writes:
> Or failing that, I'd at least like to understand why the planner
> is deciding not to use the category_lang index when the result
> set is coming from a function instead of a "regular" table.

The planner defaults to assuming that set-returning functions return
1000 rows (as you can see in the EXPLAIN output). A plan that would
win for a single returned row would lose badly at 1000 rows ...
and vice versa. See the archives for various debates about how to
get a better estimate; it's not an easy problem.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Andrus 2006-06-06 09:57:31 Re: How to force Postgres to use index on ILIKE
Previous Message Dan Libby 2006-06-06 00:03:59 Problem: query becomes slow when calling a fast user defined function.