On Fri, 2009-10-23 at 07:18 +0200, Jesper Krogh wrote:
> This is indeed information on individual terms from the statistics that
> enable this.
My mistake, I didn't know it was that smart about it.
> > In effect, what you want are words that aren't searched (or stored) in
> > the index, but are i
Jeff Davis wrote:
> On Thu, 2009-10-22 at 18:28 +0200, Jesper Krogh wrote:
>> I somehow would expect the index-search to take advantage of the MCV's
>> informations in the statistics that sort of translate it into a search
>> and post-filtering (as PG's queryplanner usually does at the SQL-level).
On Thu, 2009-10-22 at 18:28 +0200, Jesper Krogh wrote:
> I somehow would expect the index-search to take advantage of the MCV's
> informations in the statistics that sort of translate it into a search
> and post-filtering (as PG's queryplanner usually does at the SQL-level).
MCVs are full values t
On 10/19/09 12:10 PM, "Robert Haas" wrote:
> 2009/10/19 Grzegorz Jaśkiewicz :
>>
>>
>> 2009/10/19 Robert Haas
>>>
>>> 2009/10/19 Grzegorz Jaśkiewicz :
On Sun, Oct 11, 2009 at 3:30 PM, Michal Szymanski
wrote:
>
> We have similar problem and now we are try to f
On 10/21/09 3:51 PM, "Doug Cole" wrote:
> I have a reporting query that is taking nearly all of it's time in aggregate
> functions and I'm trying to figure out how to optimize it. The query takes
> approximately 170ms when run with "select *", but when run with all the
> aggregate functions t
On 10/22/09 12:25 PM, "Kevin Grittner" wrote:
> Kevin Buckham wrote:
>
>> Our primary location table is clustered by "reporttime" (bigint).
>> Many of the queries we need to perform are of the nature : "get me
>> all positions from a given device for yesterday". Similar queries
>> are "get m
Kevin Buckham wrote:
> Our primary location table is clustered by "reporttime" (bigint).
> Many of the queries we need to perform are of the nature : "get me
> all positions from a given device for yesterday". Similar queries
> are "get me the most recent 10 positions from a given device".
H
I am running several servers with Postgres 8.3 that are used to house
location data from thousands of devices. Location updates are quite
frequent, so our tables rapidly become fairly large (often about 2GB per
day of growth). We've been using Postgres for close to 10 years now and
have been very
Jesper Krogh wrote:
> I'm searching the gin-index for 1-5 terms, where all of them matches
> the same document. TERM1 is unique by itself, TERM2 is a bit more
> common (52 rows), TERM3 more common, TERM4 close to all and TERM5
> all records.
>Recheck Cond: (ftsbody_body_fts @@
Hi
My indexing base is now up to 7.5m documents, I have raise statistics
target to 1000 for the tsvector column in order to make the
query-planner choose more correctly. That works excellent.
Table structure is still:
ftstest=# \d ftsbody
Table "public.ftsbody"
On Wed, Oct 21, 2009 at 10:21 PM, Doug Cole wrote:
> On Wed, Oct 21, 2009 at 5:39 PM, Merlin Moncure wrote:
>>
>> On Wed, Oct 21, 2009 at 6:51 PM, Doug Cole wrote:
>> > I have a reporting query that is taking nearly all of it's time in
>> > aggregate
>> > functions and I'm trying to figure out
On Wed, Oct 21, 2009 at 03:51:25PM -0700, Doug Cole wrote:
> I have a reporting query that is taking nearly all of it's time in aggregate
> functions and I'm trying to figure out how to optimize it. The query takes
> approximately 170ms when run with "select *", but when run with all the
> aggrega
Le jeudi 22 octobre 2009 00:06:10, Scott Marlowe a écrit :
> On Wed, Oct 21, 2009 at 11:17 AM, Scott Carey
wrote:
> > On 10/15/09 11:27 PM, "Albe Laurenz" wrote:
> >> waldomiro wrote:
> >>> I need to know how much the postgres is going to disk to get
> >>> blocks and how much it is going to cach
13 matches
Mail list logo
