Bruce Momjian writes:
> OK, can you add it or give me wording, or it is already on the TODO
> list?
It's already there.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
Andrew Dunstan wrote:
>
>
> On 11/12/2010 01:11 PM, Bruce Momjian wrote:
> > Josh Berkus wrote:
> >> On 10/08/2010 02:44 PM, Robert Haas wrote:
> In any case, I would expect that GIN could actually do this quite
> efficiently. What we'd probably want is a concept of a "null word",
On 11/12/2010 01:11 PM, Bruce Momjian wrote:
Josh Berkus wrote:
On 10/08/2010 02:44 PM, Robert Haas wrote:
In any case, I would expect that GIN could actually do this quite
efficiently. What we'd probably want is a concept of a "null word",
with empty indexable rows entered in the inde
Josh Berkus wrote:
> On 10/08/2010 02:44 PM, Robert Haas wrote:
> >> In any case, I would expect that GIN could actually do this quite
> >> efficiently. What we'd probably want is a concept of a "null word",
> >> with empty indexable rows entered in the index as if they contained the
> >> null
On 10/08/2010 02:44 PM, Robert Haas wrote:
In any case, I would expect that GIN could actually do this quite
efficiently. What we'd probably want is a concept of a "null word",
with empty indexable rows entered in the index as if they contained the
null word. So there'd be just one index en
On Oct 8, 2010, at 1:47 PM, Tom Lane wrote:
> How so? In a typical application, there would not likely be very many
> such rows --- we're talking about cases like documents containing zero
> indexable words. In any case, the problem right now is that GIN has
> significant functional limitations
On Fri, Oct 8, 2010 at 1:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Oct 7, 2010 at 10:52 PM, Tom Lane wrote:
>>> IMO, what's needed is to fix GIN so it doesn't go insane for empty
>>> values or non-restrictive queries, by ensuring there's at least one
>>> index entry for every row.
Robert Haas writes:
> On Thu, Oct 7, 2010 at 10:52 PM, Tom Lane wrote:
>> IMO, what's needed is to fix GIN so it doesn't go insane for empty
>> values or non-restrictive queries, by ensuring there's at least one
>> index entry for every row. This has been discussed before; see the TODO
>> sectio
On Thu, Oct 7, 2010 at 10:52 PM, Tom Lane wrote:
> Josh Berkus writes:
>> I thought we fixed this in 8.4.4, but apparently not. In the event that
>> you have a GIN index containing a WHERE clause which is sufficiently
>> restrictive, PostgreSQL will attempt to use the index even though it
>> can
IMO, what's needed is to fix GIN so it doesn't go insane for empty
values or non-restrictive queries, by ensuring there's at least one
index entry for every row. This has been discussed before; see the TODO
section for GIN.
Well, what is that fix waiting on, then? Oleg, Teodor? We may even
Josh Berkus writes:
> I thought we fixed this in 8.4.4, but apparently not. In the event that
> you have a GIN index containing a WHERE clause which is sufficiently
> restrictive, PostgreSQL will attempt to use the index even though it
> can't.
We could probably kluge the planner to avoid that c
All,
I thought we fixed this in 8.4.4, but apparently not. In the event that
you have a GIN index containing a WHERE clause which is sufficiently
restrictive, PostgreSQL will attempt to use the index even though it
can't. Since this is completely out of the control of the user, it
effectively pr
12 matches
Mail list logo
