Vitaliy Gomenyuk <vgomenyuk@callfire.com> writes:
> [ same query slower on slave ]
Hmm, the discrepancy is evidently in the larger bitmap index scan:
> There is an execution plan from master:
> -> Bitmap Index Scan on "OutgoingMessages_Status_StampToSend_Deleted" (cost=0.00..3556.90
rows=80249width=0) (actual time=139.761..139.761 rows=9158 loops=1)
> Index Cond: ((om."Status" = 0) AND (om."Deleted" = false))
> Buffers: shared hit=70252
> There is an execution plan from slave:
> -> Bitmap Index Scan on "OutgoingMessages_Status_StampToSend_Deleted" (cost=0.00..3556.90
rows=80249width=0) (actual time=1470.853..1470.853 rows=8671249 loops=1)
> Index Cond: ((om."Status" = 0) AND (om."Deleted" = false))
> Buffers: shared hit=70252
The contents of the indexes should be the same, so why is the slave
returning so many more rows? It has to be because the index entries are
not marked as killed (known-dead-to-everybody), or not being treated as
killed, in the slave. I vaguely recall that there's a difference in the
rules for index entry visibility on slaves, but it's not clear to me why
that should be.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
