Re: tsvector pg_stats seems quite a bit off.

From: Jesper Krogh <jesper(at)krogh(dot)cc>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Urbański <wulczer(at)wulczer(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: tsvector pg_stats seems quite a bit off.
Date: 2010-06-01 04:50:45
Message-ID: 4C0491A5.6030006@krogh.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2010-05-31 20:38, Tom Lane wrote:
> Jesper Krogh<jesper(at)krogh(dot)cc> writes:
>
>> Just a small follow up. I tried out the patch (or actually a fresh git
>> checkout) and it now gives very accurate results for both upper and
>> lower end of the MCE-histogram with a lower cutoff that doesn't
>> approach 2.
>>
> Good. How much did the ANALYZE time change for your table?
>
1.3m documents.

New code ( 3 runs):
statistics target 1000 => 155s/124s/110s
statictics target 100 => 86s/55s/61s
Old code:
statistics target 1000 => 158s/101s/99s
statistics target 100 => 90s/29s/33s

Somehow I think that the first run is the relevant one, its pretty much
a "dead disk" test,
and I wouldn't expect that random sampling of tuples would have any sane
caching
effect in a production system. But it looks like the algoritm is "a bit"
slower.

Thanks again..

Jesper

--
Jesper

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2010-06-01 05:06:10 Re: Open Item: pg_controldata - machine readable?
Previous Message Pavel Stehule 2010-06-01 04:40:56 Re: functional call named notation clashes with SQL feature