@postgresql.org; Oleg Bartunov
Subject: Re: [PERFORM] rtree/gist index taking enormous amount of space
in 8.2.3
> Oleg, Teodor, can this be improved?
Attached patch improves creation of index for similar corner cases. And
split
algorithm still demonstrates O(n).
It possible to make fallback to Guttma
dor Sigaev
Subject: Re: [PERFORM] rtree/gist index taking enormous amount of space
in 8.2.3
"Dolafi, Tom" <[EMAIL PROTECTED]> writes:
> min(fmin) | max(fmin)|avg(fmin)
>1 | 55296469 |11423945
> min(fmax) | max(fmax)|
-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Friday, June 29, 2007 2:38 PM
To: Dolafi, Tom
Cc: pgsql-performance@postgresql.org; Oleg Bartunov; Teodor Sigaev
Subject: Re: [PERFORM] rtree/gist index taking enormous amount of space
in 8.2.3
"Dolafi, Tom" <[EMAIL PROTECTED]>
ogus" rows with negative values which were excluded from
the queries.
Thanks,
Tom
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Friday, June 29, 2007 2:30 PM
To: Dolafi, Tom
Cc: Craig James; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] rtree/gist i
"Dolafi, Tom" <[EMAIL PROTECTED]> writes:
> In the mean time I've dropped the index which has resulted in overall
> performance gain on queries against the table, but we have not tested
> the part of the application which would utilize this index.
I noted that with the same (guessed-at) distributi
"Dolafi, Tom" <[EMAIL PROTECTED]> writes:
> The data is not distributed well...
Can you show us min, max, and avg of fmax minus fmin? I'd like to
check my guess about that being a fairly narrow range.
regards, tom lane
---(end of broadcast)---
@postgresql.org
Subject: Re: [PERFORM] rtree/gist index taking enormous amount of space
in 8.2.3
Dolafi, Tom wrote:
> min(fmin) | max(fmin)|avg(fmin)
>1 | 55296469 |11423945
>
> min(fmax) | max(fmax)|avg(fmax)
> 18 | 3288
"Dolafi, Tom" <[EMAIL PROTECTED]> writes:
> min(fmin) | max(fmin)|avg(fmin)
>1 | 55296469 |11423945
> min(fmax) | max(fmax)|avg(fmax)
> 18 | 3288 |11424491
OK, I was able to reproduce a problem after making the further guess
th
Dolafi, Tom wrote:
min(fmin) | max(fmin)|avg(fmin)
1 | 55296469 |11423945
min(fmax) | max(fmax)|avg(fmax)
18 | 3288 |11424491
There are 5,704,211 rows in the table.
When you're looking for weird index problems, it's more in
the two constants seem to represent the notion of infinity.
Thanks,
Tom
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 28, 2007 12:09 PM
To: Dolafi, Tom
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] rtree/gist index taking enormous amount of
"Dolafi, Tom" <[EMAIL PROTECTED]> writes:
> In version 8.1.5, I have an rtree index on a 1.5 GB table. The size of
> this index is 500 MB. After migrating to 8.2.3, the size of this index
> has increased to 35GB. I've dropped are recreated the index and got the
> same result. In 8.2.3 the index
Hi,
In version 8.1.5, I have an rtree index on a 1.5 GB table. The size of
this index is 500 MB. After migrating to 8.2.3, the size of this index
has increased to 35GB. I've dropped are recreated the index and got the
same result. In 8.2.3 the index type is gist, does this have something
to
12 matches
Mail list logo
