| From: | Andrew Borodin <borodin(at)octonica(dot)com> |
|---|---|
| To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, kskim(at)bitnine(dot)net, Lukas Fittl <lukas(at)fittl(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Btree Index on PostgreSQL and Wiredtiger (MongoDB3.2) |
| Date: | 2016-08-15 08:39:30 |
| Message-ID: | CAJEAwVHc00_7_iLH07Eh6CTtMaTgREkNZ5hbtLyGVEGEVOLJzA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>So on average in a large randomly filled index, pages
spend more time nearer 50% full than 100% full.
I think we can make this number more...controllable.
Before split we can check whether left and right pages both are in
shared buffer and if they are seriously under certain fillfactor, say
under 75%. We can unload some of data there instead of spliting. This
will slow down insertions a bit, but we can have any fillfactor we
want for random inserts. I mean, for sure, someone can construct bad
input to gain low fillfactor, like it is with qsort (
http://www.cs.dartmouth.edu/~doug/mdmspe.pdf ), but every real
scenario will not trigger this behavior.
But then we have to think about locks, WALs etc.
Best regards, Andrey Borodin, Octonica & Ural Federal University.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aleksander Alekseev | 2016-08-15 09:12:16 | Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) |
| Previous Message | Artur Zakirov | 2016-08-15 08:24:07 | Re: to_date_valid() |