From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Delaying the planning of unnamed statements until Bind |
Date: | 2004-05-22 06:04:29 |
Message-ID: | 871xldq9oy.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)MIT(dot)EDU> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> > select * from mytable where entry_time >= $1;
> >
> > The planner will take a seqscan when it sees this because it is worried
> > about the downside if a large fraction of the table is being selected.
I'll mention another factor that's hidden here: The type of application that
cares about parse/optimization time enough and cares about plan stability
enough to reuse plans would be an OLTP application. The type of application
that would want to delay optimization until the parameters are known to
provide the best plan would be a DSS application or ad-hoc query.
So the very fact that the user is using placeholders like this is evidence
that the optimizer should err in the direction of assuming quick, very
selective queries.
If the specific value of $1 would help a large ad-hoc batch report run quicker
the user always has the option of providing it. The OLTP application running
thousands of queries per second doesn't have the option of doing that without
a serious performance hit.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew T. O'Connor | 2004-05-22 07:47:56 | pg_autovacuum fixes |
Previous Message | Greg Stark | 2004-05-22 05:56:54 | Re: Delaying the planning of unnamed statements until Bind |