On 2010-12-21 21:28, Andres Freund wrote:
On Tuesday 21 December 2010 20:25:16 Jesper Krogh wrote:
What have I missed in the logic?
A reproducible testcase ;-)
Yes, I did a complete dump/restore of the dataset and the numbers
looked like expected. So table bloat seems to be the
Heikki Linnakangas writes:
> On 21.12.2010 21:25, Jesper Krogh wrote:
>> Or is a Bitmap Heap Scan simply 3 times faster than a Seq-scan for
>> visibillity-testing?
> It certainly shouldn't be.
>> What have I missed in the logic?
> Perhaps you have a lot of empty space or dead tuples that don't
On Tuesday 21 December 2010 20:25:16 Jesper Krogh wrote:
> What have I missed in the logic?
A reproducible testcase ;-)
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 21.12.2010 21:25, Jesper Krogh wrote:
The first query should have the cost of the GIN-search +
visibillity-test of 158K tuples,
the latter should have the cost of visibillity-testing 168K tuples. If
we set the cost
of actually searching GIN to 0 then the gin-search - visibillity costs:
95/1580
Hi Hackers.
I have a feeling that GIN is "cheating" on the visibillity checks:
test=# set enable_seqscan = off;
SET
Time: 0.129 ms
test=# select count(id) from fts_test where fts @@ to_tsquery('core');
count
158827
(1 row)
Time: 95.530 ms
test=# explain select count(id) from fts_test