I looked into the complaint here of poor estimation for GIN
indexscans:
http://archives.postgresql.org/pgsql-performance/2012-02/msg00028.php
At first glance it sounds like a mistake in selectivity estimation,
but it isn't: the rowcount estimates are pretty nearly dead on.
The problem is in
On Mon, Feb 20, 2012 at 10:18:31AM +0100, Marc Mamin wrote:
I looked into the complaint here of poor estimation for GIN
indexscans:
http://archives.postgresql.org/pgsql-performance/2012-02/msg00028.php
At first glance it sounds like a mistake in selectivity estimation,
but it isn't: the
Hi Marc,
Do you happen to know in which function, the extra time for the toast
storage is spent -- zlib compression? I saw a mention of the LZ4
compression
algorithm that is BSD licensed as a Google summer of code project:
http://code.google.com/p/lz4/
that compresses at almost 7X
I looked into the complaint here of poor estimation for GIN indexscans:
http://archives.postgresql.org/pgsql-performance/2012-02/msg00028.php
At first glance it sounds like a mistake in selectivity estimation,
but it isn't: the rowcount estimates are pretty nearly dead on.
The problem is in the
I wrote:
BTW, an entirely different line of thought is why on earth is @@ so
frickin expensive, when it's comparing already-processed tsvectors
with only a few entries to an already-processed tsquery with only one
entry??. This test case suggests to me that there's something
unnecessarily
On Thu, Feb 16, 2012 at 6:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
BTW, an entirely different line of thought is why on earth is @@ so
frickin expensive, when it's comparing already-processed tsvectors
with only a few entries to an already-processed tsquery with only one
entry??.
Robert Haas robertmh...@gmail.com writes:
This issue of detoasting costs comes up a lot, specifically in
reference to @@. I wonder if we shouldn't try to apply some quick and
dirty hack in time for 9.2, like maybe random_page_cost for every row
or every attribute we think will require
Hi.
First, thanks for looking at this. Except from GIN indexes and
full-text-search being really good in our applications, this also
points to those excact places where it can be improved.
On 2012-02-17 00:15, Tom Lane wrote:
I looked into the complaint here of poor estimation for GIN
