Re: [HACKERS] A Better External Sort?
От | Dann Corbit |
---|---|
Тема | Re: [HACKERS] A Better External Sort? |
Дата | |
Msg-id | D425483C2C5C9F49B5B7A41F8944154757D147@postal.corporate.connx.com обсуждение исходный текст |
Ответ на | [HACKERS] A Better External Sort? (Ron Peacetree <rjpeace@earthlink.net>) |
Список | pgsql-performance |
Judy definitely rates a WOW!! > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers- > owner@postgresql.org] On Behalf Of Gregory Maxwell > Sent: Friday, September 30, 2005 7:07 PM > To: Ron Peacetree > Cc: Jeffrey W. Baker; pgsql-hackers@postgresql.org; pgsql- > performance@postgresql.org > Subject: Re: [HACKERS] [PERFORM] A Better External Sort? > > On 9/28/05, Ron Peacetree <rjpeace@earthlink.net> wrote: > > 2= We use my method to sort two different tables. We now have these > > very efficient representations of a specific ordering on these tables. > A > > join operation can now be done using these Btrees rather than the > > original data tables that involves less overhead than many current > > methods. > > If we want to make joins very fast we should implement them using RD > trees. For the example cases where a join against a very large table > will produce a much smaller output, a RD tree will provide pretty much > the optimal behavior at a very low memory cost. > > On the subject of high speed tree code for in-core applications, you > should check out http://judy.sourceforge.net/ . The performance > (insert, remove, lookup, AND storage) is really quite impressive. > Producing cache friendly code is harder than one might expect, and it > appears the judy library has already done a lot of the hard work. > Though it is *L*GPLed, so perhaps that might scare some here away from > it. :) and good luck directly doing joins with a LC-TRIE. ;) > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend
В списке pgsql-performance по дате отправления: