From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: kill_prior_tuple for bitmap scan |
Date: | 2006-06-19 03:55:09 |
Message-ID: | 9585.1150689309@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> As I read, the kill_prior_tuple optimization doesn't work for bitmap scan
> code. To fix this problem, we have two choices.
> One is still use the kill_prior_tuple trick in a modified way. Heap TIDs
> recycling should not be a problem. This is because generally we always hold
> pin of the last index page we scanned,
Really? An indexscan will release pin before returning no-more-tuples,
and had better do so else we leak pins during queries involving many
indexscans. (IIRC, I broke that around 7.3 :-()
> Another smaller problem is that we have
> to scan the heap pages again to identify the index pointers, but that's
> affordable since these pages should be in the buffer pool with big chance.
Not sure I believe that either. Even granting the assumption that the
pages are still in cache, this implies a big increase in bufmgr traffic.
This certainly is an interesting problem, but there is not a simple
solution.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | ITAGAKI Takahiro | 2006-06-19 05:05:05 | Re: table/index fillfactor control, try 2 |
Previous Message | Qingqing Zhou | 2006-06-19 03:34:06 | kill_prior_tuple for bitmap scan |