Re: Fast insertion indexes: why no developments

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.