Re: Problem with bitmap-index-scan plan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jkapad(at)csd(dot)uoc(dot)gr
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Problem with bitmap-index-scan plan
Date: 2006-07-13 22:32:58
Message-ID: 21981.1152829978@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

jkapad(at)csd(dot)uoc(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mark Kirkwood 2006-07-14 01:30:39 Re: Kill a session
Previous Message Medora Schauer 2006-07-13 18:25:03 Re: hyper slow after upgrade to 8.1.4