Re: BRIN index worse than sequential scan for large search set

2023-02-24 Thread Justin Pryzby
On Fri, Feb 24, 2023 at 06:51:00PM +0100, Mickael van der Beek wrote: > Hello Justin, > > Thanks for the quick response! > > > The table may be dense, but the tuples aren't. You're asking to return > > 1/1000th of the tuples, across the entire table. Suppose there are ~100 > > tuples per page,

Re: BRIN index worse than sequential scan for large search set

2023-02-24 Thread Mickael van der Beek
Hello Justin, Thanks for the quick response! The table may be dense, but the tuples aren't. You're asking to return > 1/1000th of the tuples, across the entire table. Suppose there are ~100 > tuples per page, and you need to read about every 10th page. It makes > sense that it's slow to read

Re: BRIN index worse than sequential scan for large search set

2023-02-24 Thread Justin Pryzby
On Fri, Feb 24, 2023 at 05:40:55PM +0100, Mickael van der Beek wrote: > Hello everyone, > > I'm playing around with BRIN indexes so as to get a feel for the feature. > During my tests, I was unable to make BRIN indexes perform better than a > sequential scan for queries searching for large value

BRIN index worse than sequential scan for large search set

2023-02-24 Thread Mickael van der Beek
Hello everyone, I'm playing around with BRIN indexes so as to get a feel for the feature. During my tests, I was unable to make BRIN indexes perform better than a sequential scan for queries searching for large value sets (20K values in the example down below). Creating the table with one single