Re: Physical append-only tables
От
Bruce Momjian
Тема
Re: Physical append-only tables
Дата
Msg-id
20161124141843.GD1668@momjian.us
Ответ на
Re: Physical append-only tables (Magnus Hagander)
Список
Дерево обсуждения
Physical append-only tables Magnus Hagander <magnus@hagander.net>
Re: Physical append-only tables Alvaro Herrera <alvherre@2ndquadrant.com>
Re: Physical append-only tables Magnus Hagander <magnus@hagander.net>
Re: Physical append-only tables Tom Lane <tgl@sss.pgh.pa.us>
Re: Physical append-only tables Magnus Hagander <magnus@hagander.net>
Re: Physical append-only tables Thomas Munro <thomas.munro@enterprisedb.com>
Re: Physical append-only tables Greg Stark <stark@mit.edu>
Re: Physical append-only tables Bruce Momjian <bruce@momjian.us>
Re: Physical append-only tables Magnus Hagander <magnus@hagander.net>
Re: Physical append-only tables Bruce Momjian <bruce@momjian.us>
Re: Physical append-only tables Jim Nasby <Jim.Nasby@BlueTreble.com>
Re: Physical append-only tables Masahiko Sawada <sawada.mshk@gmail.com>
Re: Physical append-only tables Magnus Hagander <magnus@hagander.net>
On Thu, Nov 24, 2016 at 10:13:30AM +0100, Magnus Hagander wrote: > On Thu, Nov 24, 2016 at 2:26 AM, Bruce Momjian wrote: > > On Mon, Nov 14, 2016 at 08:43:12PM +0000, Greg Stark wrote: > > That said, I don't think the "maintain clustering a bit better using > > BRIN" is a bad idea. It's just the bit about turning a table > > append-only to deal with update-once data that I think is overreach. > > What if we used BRIN to find heap pages where the new row was in the > page BRIN min/max range, and the heap page had free space. Only if that > fails do we put is somewhere else in the heap. > > > That would certainly be useful. You'd have to figure out what to do in the case > of multiple conflicting BRIN indexes (which you shouldn't have in the first > place, but that won't keep people from having them), but other than that it > would be quite good I think. This idea is only possible because the BRIN index is so small and easy to scan, i.e. this wouldn't work for a btree index. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-hackers по дате отправления