Re: Optimizing away second VACUUM heap scan when only BRIN indexes on table

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimizing away second VACUUM heap scan when only BRIN indexes on table
Date: 2015-12-21 09:35:14
Message-ID: CAM3SWZQNe8tAiq-533YawzERwpcDh+HFo0zjmWkY=ESSUXe4KQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 21, 2015 at 1:24 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> Given BRIN's characteristics, such a table design is compelling when the
> table is very large, yet possible only for certain use cases.

You can say the same thing about BRIN itself, of course.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2015-12-21 10:33:36 Re: Parallel Aggregate
Previous Message Simon Riggs 2015-12-21 09:24:40 Re: Optimizing away second VACUUM heap scan when only BRIN indexes on table