On Tue, Jun 14, 2016 at 03:24:12PM -0500, Jim Nasby wrote:
> On 6/8/16 4:36 PM, Bruce Momjian wrote:
> >Just a follow-up, but even with a randomized correlation order, it seems
> >25% restrictivity generates a Bitmap Index Scan:
>
> AFAIK we do the bitmap heap scan in heap order, thereby eliminati
On 6/8/16 4:36 PM, Bruce Momjian wrote:
Just a follow-up, but even with a randomized correlation order, it seems
25% restrictivity generates a Bitmap Index Scan:
AFAIK we do the bitmap heap scan in heap order, thereby eliminating the
effect of correlation?
--
Jim Nasby, Data Architect, Blue T
On Wed, Jun 8, 2016 at 05:07:34PM -0400, Bruce Momjian wrote:
> > For randomly-ordered data I believe the cutover is actually well below 10%.
>
> Ah, I had not considered the correlation order of the rows in the table.
> This test returns the sequential scan I expected by using floor(random()
> *
On Wed, Jun 8, 2016 at 01:28:54PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > As part of my research on the parsing/planning behavior of PREPARE, I
> > found a surprising behavior --- a WHERE clause that is 50% restrictive
> > is using an index. I thought only <10% restrictions used index
Bruce Momjian writes:
> As part of my research on the parsing/planning behavior of PREPARE, I
> found a surprising behavior --- a WHERE clause that is 50% restrictive
> is using an index. I thought only <10% restrictions used indexes.
There's no such hard-and-fast rule. The cost estimate break
