Re: BRIN index on timestamptz - Mailing list pgsql-general

From Tomas Vondra
Subject Re: BRIN index on timestamptz
Date
Msg-id abf9aacc-cd77-b08d-311e-7bc932f4ddd8@enterprisedb.com
Whole thread Raw
In response to BRIN index on timestamptz  (Mohan Radhakrishnan <radhakrishnan.mohan@gmail.com>)
Responses Re: BRIN index on timestamptz  (Mohan Radhakrishnan <radhakrishnan.mohan@gmail.com>)
List pgsql-general

On 4/23/21 10:31 AM, Mohan Radhakrishnan wrote:
> Hi,
>           I am planning to use as I search based on timestamptz fields. 
> There are millions of records.I refer 
> https://www.percona.com/blog/2019/07/16/brin-index-for-postgresql-dont-forget-the-benefits 
> <https://www.percona.com/blog/2019/07/16/brin-index-for-postgresql-dont-forget-the-benefits>
> 
> I execute this on the AWS RDS instance. Is there something in the plan I 
> should pay attention to ? I notice the Execution Time.
> 
> Thanks,
> Mohan
> 
> INSERT INTO testtab (id, date, level, msg) SELECT g, CURRENT_TIMESTAMP + 
> ( g || 'minute' ) :: interval, random() * 6, md5(g::text) FROM 
> generate_series(1,8000000) as g;

Two things:

a) You need to do ANALYZE, otherwise there are no statistics the 
optimizer could use (which is why the row estimates in the plans are 
entirely bogus).

b) BRIN indexes don't work on random data, because the whole idea is 
about eliminating large blocks of data (e.g. 1MB). But with random data 
that's not going to happen, because each such range will match anything. 
Which is why seqscan is a bit faster than when using BRIN index.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: server process exited with code 1
Next
From: Mohan Radhakrishnan
Date:
Subject: Re: BRIN index on timestamptz