Oleg Bartunov writes:
> On Thu, 29 Apr 2010, Tom Lane wrote:
>> There's a fuzz factor of (IIRC) 1% in path cost comparisons. It's
>> deciding that the seqscan and bitmapscan total costs are not
>> meaningfully different; then since the startup costs *are* meaningfully
>> different, it's making th
On Thu, 29 Apr 2010, Tom Lane wrote:
Teodor Sigaev writes:
[ planner prefers ]
-> Seq Scan on foo (cost=0.00..5805.00 rows=4907 width=0)
to
-> Bitmap Heap Scan on foo (cost=942.46..5755.08 rows=4907 width=0)
Why does pgsql choose seqscan (5817.28) instead of bitmap one (5767.36)
Teodor Sigaev writes:
> [ planner prefers ]
> -> Seq Scan on foo (cost=0.00..5805.00 rows=4907 width=0)
> to
> -> Bitmap Heap Scan on foo (cost=942.46..5755.08 rows=4907 width=0)
> Why does pgsql choose seqscan (5817.28) instead of bitmap one (5767.36)?
There's a fuzz factor of (IIRC
2010/4/29 Teodor Sigaev :
> Hi!
>
> There is some strange on current CVS with correct choosing of scans.
Also true with 8.4, default configuration.
> Although bitmap scan is cheaper but postgresql chooses seqscan. Test suite:
>
> CREATE OR REPLACE FUNCTION genvect()
> RETURNS tsvector AS
> $$
>
Hi!
There is some strange on current CVS with correct choosing of scans. Although
bitmap scan is cheaper but postgresql chooses seqscan. Test suite:
CREATE OR REPLACE FUNCTION genvect()
RETURNS tsvector AS
$$
SELECT
array_to_string(
ARRAY(
SELECT
