From: | Kapadaidakis Yannis <jkapad(at)csd(dot)uoc(dot)gr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Problem with bitmap-index-scan plan |
Date: | 2006-07-18 09:25:44 |
Message-ID: | Pine.GSO.4.64.0607181224540.11316@oneiro.csd.uoc.gr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Yes that was the problem! Thank you very much
On Thu, 13 Jul 2006, Tom Lane wrote:
> 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
>
> ---------------------------(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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Sherry | 2006-07-18 12:22:57 | Re: Temporary table retains old contents on update eventually |
Previous Message | Gabriele Turchi | 2006-07-18 07:25:40 | Re: Big differences in plans between 8.0 and 8.1 |