Re: Problem with bitmap-index-scan plan
От | Kapadaidakis Yannis |
---|---|
Тема | Re: Problem with bitmap-index-scan plan |
Дата | |
Msg-id | Pine.GSO.4.64.0607181224540.11316@oneiro.csd.uoc.gr обсуждение исходный текст |
Ответ на | Re: Problem with bitmap-index-scan plan (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
Yes that was the problem! Thank you very much On Thu, 13 Jul 2006, Tom Lane wrote: > jkapad@csd.uoc.gr writes: >> ... is quite reasonable.The table has 1.000.000 rows (17.242 pages). From >> pg_stat_get_blocks_fetched I can see that there were 102 page requests for >> table. So all things seem to work great here! > >> But if I multiply the size of the table ten-times (10.000.000 rows - 172.414 >> pages) and run the same query I get: >> ... >> which is slower even than a seq scan. Now I get that there were 131.398 page >> requests for table in order to retrieve almost 1250 tuples!Can someone explain >> why this is happening? All memory parameters are set to default. > > You probably need to increase work_mem so that the bitmaps don't become > lossy ... > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match >
В списке pgsql-performance по дате отправления: