Tom Lane <tgl@sss.pgh.pa.us> writes:
> Kyle Bateman <kyle@actarg.com> writes:
>> I dumped the log (-d 9) from the postmaster and the plan confirms that
>> the scan is sequential when called from within the function but indexed
>> when the SQL is called directly.
> Yikes, that does sound like a bug.
Actually, after further thought I realize that there is a reason for
plans within functions to be different from plans of hand-entered
queries. In the latter case the optimizer knows the constant values
(eg, it sees "WHERE to_proj = 50"), in the former case it doesn't
(eg, it sees "WHERE to_proj = $1") and has to fall back on guesses
about selectivities.
In the particular case at hand I've have expected it to pick an
indexscan anyway, but maybe there's just something weird about your
data. Could I trouble you for the vacuum stats for that table?
Easiest way to get them is
select attname,attdisbursion,s.*
from pg_statistic s, pg_attribute a, pg_class c
where starelid = c.oid and attrelid = c.oid and staattnum = attnum
and relname = 'FOO';
(I'm beginning to think we should create a standard system view
for this query ;-))
regards, tom lane
