From: | "George Pavlov" <gpavlov(at)mynewplace(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: index vs. seq scan choice? |
Date: | 2007-06-07 22:52:16 |
Message-ID: | 8C5B026B51B6854CBE88121DBF097A86DEA6D3@ehost010-33.exch010.intermedia.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-www |
> From: Tom Lane
> "George Pavlov" <gpavlov(at)mynewplace(dot)com> writes:
> >> From: Joshua D. Drake [mailto:jd(at)commandprompt(dot)com]
> >> In those rare cases wouldn't it make more sense to just set
> >> enable_seqscan to off; run query; set enable_seqscan to on;
>
> > 1. these cases are not that rare (to me);
>
> It strikes me that you probably need to adjust the planner cost
> parameters to reflect reality on your system. Usually dropping
> random_page_cost is the way to bias the thing more in favor of
> index scans.
Thanks, Tom, I will try that. Seems better than fiddling with
enable_seqscan around every query/transaction.
Joshua, I fail to understand why setting and unsetting enable_seqscan on
a per query/transaction basis is in any way preferable to query hints?
Don't get me wrong, I don't like the idea of hints, and I have read the
archives on the subject and I agree with the philosophy, but if the
optimization toolkit for routine application queries is going to include
setting config parameters that just smacks of hints by another name...
George
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2007-06-07 22:59:06 | Re: index vs. seq scan choice? |
Previous Message | Coffin, Ronald | 2007-06-07 22:44:31 | Re: [ANNOUNCE] Advisory on possibly insecure security definer functions |
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2007-06-07 22:59:06 | Re: index vs. seq scan choice? |
Previous Message | Tom Lane | 2007-06-07 22:33:48 | Re: index vs. seq scan choice? |