Hi Scott,
Thanks for you suggestion. I have follow your suggestion by disable
nestloop and have a substantial improvement. Takes 51s now. I have
attached the new query plan in another file.
What I want to ask is, is there any other way to hint the planner to
choose to use merge join rather than n
On Sun, Aug 9, 2009 at 3:26 PM, Fizu wrote:
> -> Index Scan using country_ranking_user_idx on "user"
> (cost=0.00..4807.25 rows=1710 width=143) (actual
> time=20.923..4898.931 rows=1972 loops=1)
> Index Cond: (country_id = 5)
An index scan that picks up 1972 row
On Sunday 09 August 2009 21:26:08 Fizu wrote:
>-> Index Scan using country_ranking_user_idx on "user"
> (cost=0.00..4807.25 rows=1710 width=143) (actual
> time=20.923..4898.931 rows=1972 loops=1)
> Index Cond: (country_id = 5)
The statistics looks good now, b
On Sat, Aug 8, 2009 at 2:09 PM, Michael Andreen wrote:
> The planner is expecting one user with country_id = 1, but instead there are
> 57309. Have you analyzed recently? Maybe increasing the statistics target will
> help.
>
> /Michael
Just after analyze user and ranking it still taking so long t
I will definitely look into this. I suspect I need to tune my kernel
settings first though...
culley
On Sat, Aug 8, 2009 at 8:40 PM, Robert Haas wrote:
> On Fri, Aug 7, 2009 at 5:24 PM, Culley Harrelson wrote:
>> Hi Everyone,
>>
>> I manage a freeBSD server that is dedicated to postgresql. The
