Re: plpgsql plan cache

From: Pierre C
Subject: Re: plpgsql plan cache
Date: ,
Msg-id: op.u8jur4ndeorkce@localhost
(view: Whole thread, Raw)
In response to: plpgsql plan cache  (Joel Jacobson)
List: pgsql-performance

Tree view

plpgsql plan cache  (Joel Jacobson, )
 Re: plpgsql plan cache  ("Pierre C", )
  Re: plpgsql plan cache  (Joel Jacobson, )
   Re: plpgsql plan cache  (Tom Lane, )
   Re: plpgsql plan cache  (Nikolas Everett, )
    Re: plpgsql plan cache  (Joel Jacobson, )
 Re: plpgsql plan cache  ("Pierre C", )

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.


pgsql-performance by date:

From: Dave Crooke
Date:
Subject: Advice requested on structuring aggregation queries
From: Joe Conway
Date:
Subject: Re: Advice requested on structuring aggregation queries