| 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: | Whole Thread | Raw Message | 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 |