On Wed, Oct 5, 2016 at 3:27 PM, Stephen Frost wrote:
> Darren,
>
> * Darren Lafreniere (dlafreni...@onezero.com) wrote:
>> Tom Lane wrote:
>> > > Gavin Wahl wrote:
>> > >> It seems trivial to accelerate a MAX or MIN query with a BRIN index. You
>> > >> just find the page range with the largest/sm
Stephen Frost wrote:
> For at least some of the common BRIN use-cases, where the rows are
> inserted in-order and never/very-rarely modified or deleted, this
> approach would work very well.
>
Thanks Stephen, this is exactly our use case.
Darren,
* Darren Lafreniere (dlafreni...@onezero.com) wrote:
> Tom Lane wrote:
> > > Gavin Wahl wrote:
> > >> It seems trivial to accelerate a MAX or MIN query with a BRIN index. You
> > >> just find the page range with the largest/smallest value, and then only
> > >> scan that one. Would that be
Tom Lane wrote:
> > Gavin Wahl wrote:
> >> It seems trivial to accelerate a MAX or MIN query with a BRIN index. You
> >> just find the page range with the largest/smallest value, and then only
> >> scan that one. Would that be hard to implement? I'm interested in
> working
> >> on it if someone c
Alvaro Herrera writes:
> Darren Lafreniere wrote:
>> We found a pgsql-hackers thread from about a year ago about optimizing
>> ORDER BY for BRIN indexes. Tom Lane suggested that he was working on it:
>> https://www.postgresql.org/message-id/11881.1443393360%40sss.pgh.pa.us
> Tom said he was worki
Ahh, yes. I misread that. Thank you for the clarification.
On Wed, Oct 5, 2016 at 2:27 PM, Alvaro Herrera
wrote:
> Darren Lafreniere wrote:
>
> > "In addition to simply finding the rows to be returned by a query, an
> index
> > may be able to deliver them in a specific sorted order. This allows
Darren Lafreniere wrote:
> "In addition to simply finding the rows to be returned by a query, an index
> may be able to deliver them in a specific sorted order. This allows a
> query's ORDER BY specification to be honored without a separate sorting
> step. Of the index types currently supported by
Hello,
We're curious about the current behavior in 9.5.4, and possible future
enhancements, of BRIN indexes with respect to ordering.
In the docs, section 11.4. "Indexes and ORDER BY" (
https://www.postgresql.org/docs/9.5/static/indexes-ordering.html) is clear
that anything other than B-tree inde
Felipe Santos wrote:
> brin_db=# EXPLAIN ANALYSE SELECT count(*) FROM orders WHERE order_date
> BETWEEN '2012-01-04 09:00:00' and '2014-01-04 14:30:00';
>
> QUERY PLAN
>
> --
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Felipe Santos
Sent: Thursday, January 28, 2016 1:17 PM
To: Joshua D. Drake
Cc: Melvin Davidson ; David Rowley
; pgsql-general@postgresql.org; Thomas Kellerer
Subject: Re: [GENERAL] BRIN indexes
Emre Hasegeli wrote:
> >> From the above, may I presume that it is best to cluster (or sort), the
> >> table based on the intended
> >> BRIN column(s) before actually creating the index to insure the pages are
> >> adjacent? If so, should
> >> that not be included in the documentation, instead of
>> From the above, may I presume that it is best to cluster (or sort), the
>> table based on the intended
>> BRIN column(s) before actually creating the index to insure the pages are
>> adjacent? If so, should
>> that not be included in the documentation, instead of implied?
The same question is
Rowley <
> david.row...@2ndquadrant.com>; pgsql-general@postgresql.org; Thomas
> Kellerer
> *Subject:* Re: [GENERAL] BRIN indexes
>
>
>
> "Further to the point, it is self defeating to have more than one BRIN
> index on the table if the columns involved would have mutual
2016-01-28 16:03 GMT-02:00 Joshua D. Drake :
> On 01/28/2016 09:41 AM, Melvin Davidson wrote:
>
>> So, IOW, and the answer to my question is yes, it should be insured that
>> all pages involved are physically adjacent (by design or by pre-sort)
>> before creating a BRIN on them.
>> Further to the
On 01/28/2016 09:41 AM, Melvin Davidson wrote:
So, IOW, and the answer to my question is yes, it should be insured that
all pages involved are physically adjacent (by design or by pre-sort)
before creating a BRIN on them.
Further to the point, it is self defeating to have more than one BRIN
index
So, IOW, and the answer to my question is yes, it should be insured that
all pages involved are physically adjacent (by design or by pre-sort)
before creating a BRIN on them.
Further to the point, it is self defeating to have more than one BRIN index
on the table if the columns involved would have
On 29 January 2016 at 06:10, Melvin Davidson wrote:
> With regard to BRIN indexes:
>
> http://www.postgresql.org/docs/9.5/interactive/brin-intro.html
>
> 62.1. Introduction
>
> "A block range is a group of pages that are physically adjacent in the
> table; for each block range, some summar
Melvin Davidson wrote:
> With regard to BRIN indexes:
>
> http://www.postgresql.org/docs/9.5/interactive/brin-intro.html
>
> 62.1. Introduction
>
> "A block range is a group of pages that are physically adjacent in the
> table; for each block range, some summary info is stored by the inde
Reposting because I received no reply from a previous inquiry as "9.5 new
features".
With regard to BRIN indexes:
http://www.postgresql.org/docs/9.5/interactive/brin-intro.html
62.1. Introduction
"A block range is a group of pages that are physically adjacent in the
table; for each block
19 matches
Mail list logo
