| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | Leonardo Francalanci <m_lists(at)yahoo(dot)it>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fast insertion indexes: why no developments |
| Date: | 2013-11-02 10:07:44 |
| Message-ID: | CA+U5nMKhePDSxcwxMNzMYTiHOx94ooydMK6AmCJ15F=zrNq_Pg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 29 October 2013 16:10, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Tue, Oct 29, 2013 at 7:53 AM, Leonardo Francalanci <m_lists(at)yahoo(dot)it> wrote:
>> I don't see much interest in insert-efficient indexes.
>
> Presumably someone will get around to implementing a btree index
> insertion buffer one day. I think that would be a particularly
> compelling optimization for us, because we could avoid ever inserting
> index tuples that are already dead when the deferred insertion
> actually occurs.
That's pretty much what the LSM-tree is.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Atri Sharma | 2013-11-02 10:54:58 | Re: Handle LIMIT/OFFSET before select clause (was: Feature request: optimizer improvement) |
| Previous Message | Stefan Kaltenbrunner | 2013-11-02 09:10:32 | Re: Record comparison compiler warning |