I've mentioned this a couple times now, but here is an official
proposal:
I would like to move the contrib/rtree_gist functionality into the core
system before feature freeze. There are a couple arguments in favor:
* It's way past time GiST indexes got some regression testing in the
core build.
Tom Lane <[EMAIL PROTECTED]> writes:
> * With the recent WAL-ization and hoped-for concurrency fixes, GiST
> is definitely superior to R-tree for practical use. I don't see the
> percentage in continuing to maintain the R-tree code indefinitely.
> By integrating the opclasses needed to replace R-
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> * With the recent WAL-ization and hoped-for concurrency fixes, GiST
>> is definitely superior to R-tree for practical use. I don't see the
>> percentage in continuing to maintain the R-tree code indefinitely.
>> By in
Also, isn't rtree still substantially faster than gist?
Not according to contrib/rtree_gist/bench/, though I admit I have not
bothered to reproduce the experiment.
Will you just remove rtree and make rtree indexes use rtree_gist instead?
Chris
---(end of broadcast)--
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Will you just remove rtree and make rtree indexes use rtree_gist instead?
That is in the back of my mind for 8.2 or so; I thought it'd be a bit
premature to propose it for 8.1, though.
The real bottom line here is that any devel effort we migh
Tom Lane Wrote:
> ... but rtree has always
> been marginal, and it's very hard to see where it can win over gist.
Simplicity!
Implementing rtree operators and support functions is FAR simpler than
implementing the GiST equivalents.
For example, suppose all you want to implement is the ~ operat
"John Hansen" <[EMAIL PROTECTED]> writes:
> Tom Lane Wrote:
>> ... but rtree has always
>> been marginal, and it's very hard to see where it can win over gist.
> Simplicity!
> Implementing rtree operators and support functions is FAR simpler than
> implementing the GiST equivalents.
Mmm ... not
Tom Lane <[EMAIL PROTECTED]> writes:
> "John Hansen" <[EMAIL PROTECTED]> writes:
>
> > Simplicity!
> > Implementing rtree operators and support functions is FAR simpler than
> > implementing the GiST equivalents.
>
> Mmm ... not really. It does seem that we could offer some sort of
> generic se
On 2005-06-27, Greg Stark <[EMAIL PROTECTED]> wrote:
> I believe all the picksplit functions are based on (apparently via
> copy/paste) a single algorithm that depends on a single operator: a kind
> of "distance" function. Usually it's the same function underlying the
> penalty gist api function.
We can make r-tree as contrib module and then we will have example of index in
contrib...
By integrating the opclasses needed to replace R-tree, we can start
down the path to deprecating and eventually removing R-tree.
--
Teodor Sigaev E-mail: [EMAIL PROTECT
I think we still have a serious problem with multicolumn indexes. As they
stand they're basically only indexes on the first column. The later columns
are not used to determine page splits.
It's not a fully truth, second keys can be used in split, if first columns has
non-unique values and secon
I believe all the picksplit functions are based on (apparently via copy/paste)
a single algorithm that depends on a single operator: a kind of "distance"
function. Usually it's the same function underlying the penalty gist api
You are wrong, at least now in contrib it used three basic picksplit
FYI, compress and decompress methods may be trivial.
For GiST you still need 7 support functions + the operator function,
some of which aren't exactly simple to implement, the picksplit for
instance.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
Tom Lane [mailto:[EMAIL PROTECTED] Wrote:
> There's no HOWTO for rtree either. Again, my point is not
> that one couldn't be written; it's that we would probably be
> better off spending the effort on a HOWTO for gist.
No, but the _current_ implementation of the rtree operators are ver much
se
"John Hansen" <[EMAIL PROTECTED]> writes:
> No, but the _current_ implementation of the rtree operators are ver much
> self explaining and need no howto.
That reasoning no doubt explains why we don't have *any* rtree-like
opclasses that got the left/overleft/right/overright semantics right
the fir
I think we still have a serious problem with multicolumn indexes. As they
stand they're basically only indexes on the first column. The later columns
are not used to determine page splits.
1. In your meaning, btree has bad split algorithm too. Look at _bt_compare, if
first keys on page are uniq
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> 1. In your meaning, btree has bad split algorithm too. Look at _bt_compare, if
> first keys on page are unique the the later keys will not be compared ;)
I'm confused now. I was under the impression that gist didn't look at
subsequent columns if the fi
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> 1. In your meaning, btree has bad split algorithm too. Look at _bt_compare, if
> first keys on page are unique the the later keys will not be compared ;)
Please look at BUG 1614/1616.
Pleeaaaeee.
There are also troubles with intarray, may be it can
On Wed, 29 Jun 2005, falcon wrote:
Teodor Sigaev <[EMAIL PROTECTED]> writes:
1. In your meaning, btree has bad split algorithm too. Look at _bt_compare, if
first keys on page are unique the the later keys will not be compared ;)
Please look at BUG 1614/1616.
Pleeaaaeee.
There are also tr
Yura,
I found your message
http://archives.postgresql.org/pgsql-bugs/2005-04/msg00213.php
So, what's the problem ? Could you reproduce your problem without
silly plpgsql functions ? Just plain create table, inserts and selects.
Also, have you tried CVS HEAD before crying too much ?
O
On Thu, 30 Jun 2005, falcon wrote:
Hello, pgsql-hackers.
Hello, Oleg Bartunov.
Here are my first messages. Bug was found on these real data in a real table.
My hairs raised. Excuse my emotionality.
http://archives.postgresql.org/pgsql-bugs/2005-04/msg00160.php
http://archives.postgresql.org/pg
Hello, pgsql-hackers.
Sorry for fludding. Bug 1614 was fixed in 8.0.3. I just tests.
--
falcon mailto:[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.post
22 matches
Mail list logo
