same result using an inner query (sorry, I
cant test it for now) such as:
select
city, temp, date
from
(select city, temp, date, row_number() over (partition by city order by temp
desc) as nr
from bar ) a1
where nr=1
Julien Theulier
De : pgsql-performance-ow...@postgresql.org
bid_date
What can be the recommendations on tuning the different costs so it can
better estimate the seq scan & index scans costs? I think the issue is
there. But didn't find any figures helping to choose the correct parameters
according to cpu & disks speed
Regards,
Julien Theulier
oin queries. After investigations, it looks like when you join
table a with table b on a column x and y and you have an index on column x
only, the planner is not able to choose the index scan. You have to build
the index corresponding exactly to the join statement btw the 2 tables
For example,by creating an new index on item_id and bid_date, the planner
has been able to choose this last index in both cases. Would it be possible
that the planner can choose in any case the closest index for queries having
outer join
Last thing, I am running Postgres 8.3.4 on a Windows laptop having 3.5Gb
RAM, 161Gb disk and dual core 2.5Gz processor
Regards,
Julien Theulier
postgresql.conf
Description: Binary data
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
