Matteo Beccati wrote:
> Bruce Momjian ha scritto:
> > Your patch has been added to the PostgreSQL unapplied patches list at:
> >
> > http://momjian.postgresql.org/cgi-bin/pgpatches
> >
> > It will be applied as soon as one of the PostgreSQL committers reviews
> > and approves it.
>
> Great.
Bruce Momjian ha scritto:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Great. I would just like to remind that Tom said:
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Matteo Beccati wrote:
> Hi,
>
> >>Moving it in contrib/ltree would be more difficult to me because it
> >>depends o
Hi,
Moving it in contrib/ltree would be more difficult to me because it
depends on other functions declared in selfuncs.c
(get_restriction_variable, etc).
I'd be willing to consider exporting those functions from selfuncs.c.
In the meanwhile here is the latest patch which uses both mcv and
Matteo Beccati <[EMAIL PROTECTED]> writes:
> Moving it in contrib/ltree would be more difficult to me because it
> depends on other functions declared in selfuncs.c
> (get_restriction_variable, etc).
I'd be willing to consider exporting those functions from selfuncs.c.
r
Tom Lane wrote:
After looking at this a little, it doesn't seem like it has much to do
with the ordinary 2-D notion of containment. In most of the core
geometric types, the "histogram" ordering is based on area, and so
testing the histogram samples against the query doesn't seem like it's
able t
Matteo Beccati <[EMAIL PROTECTED]> writes:
> This also made me think: is there a reason why geometric selectivity
> functions return constant values rather than checking statistics for a
> better result?
Because no one's ever bothered to work on them. You should talk to
the PostGIS guys, howeve
Matteo Beccati <[EMAIL PROTECTED]> writes:
> Someone on IRC (AndrewSN if I'm not wrong) pointed out that the
> restriction selectivity function for <@ is contsel, which returns a
> constant value of 0.001. So I started digging in the source code trying
> to understand how the default behaviour c
Hi,
I've recently had problems with slow queries caused by the selectivity
of the <@ ltree operator, as you may see in my post here:
http://archives.postgresql.org/pgsql-performance/2005-07/msg00473.php
Someone on IRC (AndrewSN if I'm not wrong) pointed out that the
restriction selectivity
