On 21 December 2015 at 09:35, Peter Geoghegan wrote:
> On Mon, Dec 21, 2015 at 1:24 AM, Simon Riggs
> 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 it
On Mon, Dec 21, 2015 at 1:24 AM, Simon Riggs 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
--
Sent via pgsql-hacker
On 21 December 2015 at 02:14, Alvaro Herrera
wrote:
> Jim Nasby wrote:
> > On 11/23/15 5:06 PM, Peter Geoghegan wrote:
> > >I realize that the second scan performed by lazy_vacuum_heap() only
> > >visits those pages known to contain dead tuples. However, the
> > >experience of seeing problems wit
On Sun, Dec 20, 2015 at 11:14:46PM -0300, Alvaro Herrera wrote:
> Jim Nasby wrote:
> > On 11/23/15 5:06 PM, Peter Geoghegan wrote:
> > >I realize that the second scan performed by lazy_vacuum_heap() only
> > >visits those pages known to contain dead tuples. However, the
> > >experience of seeing pr
On Sun, Dec 20, 2015 at 6:14 PM, Alvaro Herrera
wrote:
> Since BRIN indexes cannot be primary keys nor unique keys, it's hard to
> be convinced that the use case of a table with only BRIN indexes is
> terribly interesting.
I'm not convinced of that.
--
Peter Geoghegan
--
Sent via pgsql-hacke
Jim Nasby wrote:
> On 11/23/15 5:06 PM, Peter Geoghegan wrote:
> >I realize that the second scan performed by lazy_vacuum_heap() only
> >visits those pages known to contain dead tuples. However, the
> >experience of seeing problems with the random sampling of ANALYZE
> >makes me think that that mig
On 11/23/15 5:06 PM, Peter Geoghegan wrote:
I realize that the second scan performed by lazy_vacuum_heap() only
visits those pages known to contain dead tuples. However, the
experience of seeing problems with the random sampling of ANALYZE
makes me think that that might not be very helpful. There
The BRIN README notes:
"""
Since no heap TIDs are stored in a BRIN index, it's not necessary to scan the
index when heap tuples are removed. It might be that some summary values can
be tightened if heap tuples have been deleted; but this would represent an
optimization opportunity only, not a cor
