default_statistics_target = 100 (tried with 500, no change). Vacuum
analyzed
before initial query, and after each change to default_statistics_target.
Modifying the statistics target is useful only if the estimates are
seriously off, which is not your case - so it won't help, at least not
Hi Tomas,
2009/9/10 t...@fuzzy.cz
default_statistics_target = 100 (tried with 500, no change). Vacuum
analyzed
before initial query, and after each change to default_statistics_target.
Modifying the statistics target is useful only if the estimates are
seriously off, which is not your
Playing around with seq_page_cost (1) and random_page_cost (1), I can get
the correct index selected. Applying those same settings to our production
server does not produce the optimal plan, though.
I doubt setting seq_page_cost and random_page_cost to the same value is
reasonable - random
bricklen brick...@gmail.com writes:
Is there any other data I can provide to shed some light on this?
The table and index definitions?
The straight indexscan would probably win if the index column order
were ofid, date instead of date, ofid. I can't tell if you have
any other queries for which
On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
bricklen brick...@gmail.com writes:
Is there any other data I can provide to shed some light on this?
The table and index definitions?
The straight indexscan would probably win if the index column order
were ofid, date
2009/9/10 t...@fuzzy.cz:
Playing around with seq_page_cost (1) and random_page_cost (1), I can get
the correct index selected. Applying those same settings to our production
server does not produce the optimal plan, though.
I doubt setting seq_page_cost and random_page_cost to the same value
On Thu, Sep 10, 2009 at 9:57 AM, Robert Haas robertmh...@gmail.com wrote:
2009/9/10 t...@fuzzy.cz:
Playing around with seq_page_cost (1) and random_page_cost (1), I can
get
the correct index selected. Applying those same settings to our
production
server does not produce the optimal
On Thu, Sep 10, 2009 at 12:56 PM, bricklen brick...@gmail.com wrote:
On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
bricklen brick...@gmail.com writes:
Is there any other data I can provide to shed some light on this?
The table and index definitions?
The straight
On Thu, Sep 10, 2009 at 10:02 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Sep 10, 2009 at 12:56 PM, bricklen brick...@gmail.com wrote:
On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
bricklen brick...@gmail.com writes:
Is there any other data I can provide
On Thu, Sep 10, 2009 at 10:07 AM, bricklen brick...@gmail.com wrote:
On Thu, Sep 10, 2009 at 10:02 AM, Robert Haas robertmh...@gmail.comwrote:
On Thu, Sep 10, 2009 at 12:56 PM, bricklen brick...@gmail.com wrote:
On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
bricklen
bricklen brick...@gmail.com writes:
I just created a new index as Tom said, and the query *does* use the new
index (where ofid precedes date in the definition).
And is it indeed faster than the other alternatives?
regards, tom lane
--
Sent via pgsql-performance
On Thu, Sep 10, 2009 at 10:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
bricklen brick...@gmail.com writes:
I just created a new index as Tom said, and the query *does* use the new
index (where ofid precedes date in the definition).
And is it indeed faster than the other alternatives?
12 matches
Mail list logo
