Hello, > > With this index, you will get a different plan like this, > > > Exactly my point, can we look at making windowing functions > smart and make use of available indexes?
I might have guessed.. > > Does this satisfies your needs? > > > Not exactly. If I have missed to mention, this is not a > production issue for me. I am trying to see if PostgreSQL > planner produces best plans for Data Warehouse and mining > oriented queries. I agree to the point. > I think Hashes can be efficiently used for sorting (and I > believe they are used for joins too when a pre-sorted data set > is not available via indexes). This again could my > misinterpretation. It is true if 'Sorting' means 'key classification without orderings'. Hashes should always appear at inner side of a join, I'm convinced. The "ordered' nature is not required for the case if outer side is already ordered. If not, separate sorting will needed. > I lost you somewhere here. My be this is above my pay-grade :-) Sorry for my crumsy english :-< > Well, at least with Oracle and DB2 planners I have seen that > the plan produced with dense_rank performs better than a series > of nested SELECT MAX(). I see your point. Although I don't know what plans they generates, and I don't see how to ordering and ranking without sorting. Could you let me see what they look like? # Nevertheless, I don't have the confidence that I can be of some # help.. -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
