Skip site navigation (1) Skip section navigation (2)

Re: Full text search - query plan? PG 8.4.1

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Jesper Krogh <jesper(at)krogh(dot)cc>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Full text search - query plan? PG 8.4.1
Date: 2009-10-23 22:08:44
Message-ID: dcc563d10910231508y6131c21ar3fa4ac851f41b92e@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, Oct 23, 2009 at 2:32 PM, Jesper Krogh <jesper(at)krogh(dot)cc> wrote:
> Tom Lane wrote:
>> Jesper Krogh <jesper(at)krogh(dot)cc> writes:
>>> Tom Lane wrote:
>>>> ... There's something strange about your tsvector index.  Maybe
>>>> it's really huge because the documents are huge?
>>
>>> huge is a relative term, but length(ts_vector(body)) is about 200 for
>>> each document. Is that huge?
>>
>> It's bigger than the toy example I was trying, but not *that* much
>> bigger.  I think maybe your index is bloated.  Try dropping and
>> recreating it and see if the estimates change any.
>
> I'm a bit reluctant to dropping it and re-creating it. It'll take a
> couple of days to regenerate, so this should hopefully not be an common
> situation for the system.

Note that if it is bloated, you can create the replacement index with
a concurrently created one, then drop the old one when the new one
finishes.  So, no time spent without an index.

> I have set the statistics target to 1000 for the tsvector, the
> documentation didn't specify any heavy negative sides of doing that and
> since that I haven't seen row estimates that are orders of magnitude off.

It increases planning time mostly.  Also increases analyze times but
not that much.

> It is build from scratch using inserts all the way to around 10m now,
> should that result in index-bloat? Can I inspect the size of bloat
> without rebuilding (or similar locking operation)?

Depends on how many lost inserts there were.  If 95% of all your
inserts failed then yeah, it would be bloated.

In response to

Responses

pgsql-performance by date

Next:From: Stephen FrostDate: 2009-10-23 22:55:40
Subject: Re: Table Clustering & Time Range Queries
Previous:From: Tom LaneDate: 2009-10-23 22:06:02
Subject: Re: Full text search - query plan? PG 8.4.1

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group