> In practice, I really doubt this would make a measurable performance > difference, since most row comparisons would arrive at a result before > they got to the lowest-order columns. > > I think your gripe may actually have to do with a misestimate of the > relative costs of hash- and sort-based grouping, but analyze results > on a toy example don't illuminate that sort of problem at all :-(
Yes, this toy example doesn't show how much time was spent on the actual sorting (of the production data, obviously). What I can do is assemble a test database with similar amount of data and repost the `explain analyze` from that if there is any interest. What I noticed in the production query was that ~1000ms was spent on sorting alone. The hack query reduced that to ~400ms. I should also note that there was plenty of work_mem and that the sort was not hitting disk. I should be able to get that going sometime early tomorrow. All I'm going to do is generate a lot of contacts by randomly choosing from a set of lastnames, firstnames, etc as well as randomly insert some number of attachments for each. I'm open to any suggestions on testing methodologies. AJ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
