> 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 almo
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'
> 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
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 indexscan
Robert Haas 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 detoasting. That's obvio
On Thu, Feb 16, 2012 at 6:30 PM, Tom Lane 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??". This test
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
> unnecessar
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 pla
