Re: SSI modularity questions
| От | Kevin Grittner |
|---|---|
| Тема | Re: SSI modularity questions |
| Дата | |
| Msg-id | 4E0A0240020000250003ECDA@gw.wicourts.gov обсуждение исходный текст |
| Ответ на | SSI modularity questions ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
| Ответы |
Re: SSI modularity questions
|
| Список | pgsql-hackers |
Heikki Linnakangas wrote: > On 28.06.2011 20:47, Kevin Grittner wrote: > Hmm, the calls in question are the ones in heapgettup() and > heapgettup_pagemode(), which are subroutines of heap_getnext(). > heap_getnext() is only used in sequential scans, so it seems safe > to remove those calls. I haven't found anything to the contrary, if I understand correctly, Dan found the same, and all the tests pass without them. Here's a patch to remove them. This makes the recently-added rs_relpredicatelocked boolean field unnecessary, so that's removed in this patch, too. >> I would like to add a test involving a lossy bitmap scan. How many >> rows are normally needed to force a bitmap scan to be lossy? > > The size of bitmaps is controlled by work_mem, so you can set > work_mem very small to cause them to become lossy earlier. Off the > top of my head I don't have any guesstimate on how many rows you > need. > >> What's the easiest way to check whether a plan is going to use (or >> is using) a lossy bitmap scan? > > Good question. There doesn't seem to be anything in the EXPLAIN > ANALYZE output to show that, so I think you'll have to resort to > adding some elog()s in the right places. OK, thanks. -Kevin
Вложения
В списке pgsql-hackers по дате отправления: