Simon Riggs wrote > From our discussions here, IMHO there is a strong case for avoiding > btrees completely for larger historical data tables. That isn't > something I had even considered as desirable before this conversation > but ISTM now that taking that approach will be more fruitful than > attempting to implement LSM trees.
Eh? I don't understand this point. How can I avoid btrees, and searching by caller_id? I don't get it... Simon Riggs wrote > Alvaro has given me some results for his patch. The figures I have are > for a 2GB table. > > Index Build Time > MinMax 11 s > Btree 96s > > Index Size > MinMax 2 pages + metapage > Btree approx 200,000 pages + metapage > > Load time > MinMax no overhead, same as raw COPY > BTree - considerably slower Great!!! This looks very promising. Were the values indexed sequential? -- View this message in context: http://postgresql.1045698.n5.nabble.com/Fast-insertion-indexes-why-no-developments-tp5776227p5778150.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
