From: | Michael Nachbaur <mike(at)nachbaur(dot)com> |
---|---|
To: | josh(at)agliodbs(dot)com |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Forcing query to use an index |
Date: | 2003-03-03 23:27:34 |
Message-ID: | B676DBF2-4DCF-11D7-90E0-000A27935D5A@nachbaur.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Monday, Mar 3, 2003, at 15:21 US/Pacific, Josh Berkus wrote:
> Micheal,
>
> Don't forget to run ANALYZE as well; this does not require a table
> lock.
Yes, I have a cron job that runs a "vacuum analyze" once every other
hour.
>> Does using "set enable_seqscan = off" impact anything else on the
>> system, or is it connection-specific? Is this the recommended way of
>> doing this, or is there another way of coercing Postgres into using
>> indexes? I'm making these queries from Perl code running in an XSP
>> page, so I'm not sure how flexible this option would be from a
>> developer point of view.
>
> Setting enable_seqscan=off is just for testing purposes, to see if the
> planner
> is making a wrong decision so that you can adjust your .conf params,
> query,
> and/or indexes to suit. The setting is *not* intended as a production
> solution.
*phew* good. Now that I know the planner is making a bad choice,
where do I go from here? Should I RTFM?
Also, the query values in the configuration file that the planner uses,
are those machine-specific or are the defaults the recommended values?
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2003-03-03 23:32:47 | Re: Forcing query to use an index |
Previous Message | Josh Berkus | 2003-03-03 23:21:48 | Re: Forcing query to use an index |