Hello,
I am trying to create a new index for high multi-dimensional indexing.
The index I'm trying to use in PR-Tree ( www.cs.duke.edu/~yike/prtree/
).
I have created a new source file in "src/backend/access/" and for now
I have created the empty functions: build, insert, vacuum, etc... I
believe
Bruce Momjian wrote:
> Magnus Hagander wrote:
>>> However, the big problem is that the expressions used in expression
>>> indexes should not change their output based on the value of a GUC
>>> variable (because it would corrupt the index), but in the case above,
>>> default_text_search_config contr
algatt wrote:
> I am trying to create a new index for high multi-dimensional indexing.
> The index I'm trying to use in PR-Tree ( www.cs.duke.edu/~yike/prtree/
> ).
>
> I have created a new source file in "src/backend/access/" and for now
> I have created the empty functions: build, insert, vacuum
On Fri, 27 Jul 2007, Bruce Momjian wrote:
Magnus Hagander wrote:
However, the big problem is that the expressions used in expression
indexes should not change their output based on the value of a GUC
variable (because it would corrupt the index), but in the case above,
default_text_search_confi
algatt,
You might find the examples of PostGIS [1] and SP-GiST [2] helpful
in implementing your PR-Tree index, although the former implements only
2D R-Trees and the latter implements tries, quadtrees, and kd-trees but
not R-Trees (and extends GiST).
Yours may be the first PostgreSQL R
Where in Texas? I might be able to assist on-site if needed (though I
don't know much about linuxes).
On Jul 25, 2007, at 11:31 AM, Gavin M. Roy wrote:
One thing to take into account is I dont have physical access to the
box (It is in TX, I am in PA). All installs but Gentoo will be
performe
On Jul 26, 2007, at 2:03 PM, Tom Lane wrote:
So maybe the *real* question to ask is why we have separate GUCs for
stats_row_level and stats_block_level. Shouldn't we fold them into a
single switch? It's hard to see what having just one of them
turned on
will save.
IIRC, the guys at Emma ha
On Jul 27, 2007, at 1:49 AM, Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
"Simon Riggs" <[EMAIL PROTECTED]> wrote:
Read the heap blocks in sequence, but make a conditional lock for
cleanup on each block. If we don't get it, sleep, then try again
when we
wake up. If we fail the second time,
On Jul 27, 2007, at 6:45 PM, Jim Nasby wrote:
On Jul 26, 2007, at 2:03 PM, Tom Lane wrote:
So maybe the *real* question to ask is why we have separate GUCs for
stats_row_level and stats_block_level. Shouldn't we fold them into a
single switch? It's hard to see what having just one of them
t