Re: plpgsql plan cache

Actually, planner was smart in using a bitmap index scan in the prepared  
query. Suppose you later EXECUTE that canned plan with a date range which  
covers say half of the table : the indexscan would be a pretty bad choice  
since it would have to access half the rows in the table in index order,  
which is potentially random disk IO. Bitmap Index Scan is slower in your  
high-selectivity case, but it can withstand much more abuse on the  
parameters.

PG supports the quite clever syntax of EXECUTE 'blah' USING params, you  
don't even need to mess with quoting.