On Thu, Sep 10, 2009 at 10:56 AM, Tom Lane wrote:
> bricklen 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, t
bricklen 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 mailing list (pgsql-per
On Thu, Sep 10, 2009 at 10:07 AM, bricklen wrote:
> On Thu, Sep 10, 2009 at 10:02 AM, Robert Haas wrote:
>
>> On Thu, Sep 10, 2009 at 12:56 PM, bricklen wrote:
>> > On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane wrote:
>> >>
>> >> bricklen writes:
>> >> > Is there any other data I can provide to sh
On Thu, Sep 10, 2009 at 10:02 AM, Robert Haas wrote:
> On Thu, Sep 10, 2009 at 12:56 PM, bricklen wrote:
> > On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane wrote:
> >>
> >> bricklen writes:
> >> > Is there any other data I can provide to shed some light on this?
> >>
> >> The table and index defini
On Thu, Sep 10, 2009 at 12:56 PM, bricklen wrote:
> On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane wrote:
>>
>> bricklen 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 c
On Thu, Sep 10, 2009 at 9:57 AM, Robert Haas wrote:
> 2009/9/10 :
> >> 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 do
2009/9/10 :
>> 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
>
On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane wrote:
> bricklen 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
bricklen 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 the existing colu
> 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 a
Hi Tomas,
2009/9/10
> > 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 -
> 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
re
In the following query, We are seeing a sub-optimal plan being chosen. The
following results are after running the query several times (after each
change).
dev1=# select version();
version
---
13 matches
Mail list logo
