> This is bogus reasoning. The limit on index entry length will not
> change when you rebuild the index.
What I meant by 'rebuilding' was not issuing a REINDEX command, but
creating a new index after having dropped the index and inserted
whatever records. Building indexes can be slow, and I'd rat
On Mon, Mar 08, 2004 at 10:26:21AM +1000, Steven Butler wrote:
> I tested my hunch by casting the constant to bigint (as can be seen below)
> and suddenly the query is using the index again.
Yes. You can make this work all the time by quoting the constant.
That is, instead of
WHERE inde
Andrew Sullivan wrote:
"Intended", no. "Expected", yes. This topic has had the best
Postgres minds work on it, and so far nobody's come up with a
solution.
Actually, this has already been fixed in CVS HEAD (as I mentioned in
this thread yesterday). To wit:
nconway=# create table t1 (a int8);
CR
On Mon, Mar 08, 2004 at 11:05:25 -0500,
Andrew Sullivan <[EMAIL PROTECTED]> wrote:
>
> "Intended", no. "Expected", yes. This topic has had the best
> Postgres minds work on it, and so far nobody's come up with a
> solution. There was a proposal to put in a special-case automatic
> fix for int
On Mon, Mar 08, 2004 at 11:22:56AM -0500, Neil Conway wrote:
> Actually, this has already been fixed in CVS HEAD (as I mentioned in
> this thread yesterday). To wit:
Yes, I saw that after I sent my mail. What can I say except, "Yay!
Good work!"
A
--
Andrew Sullivan | [EMAIL PROTECTED]
This
Tom Lane wrote:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Just a suggestion, please use diff -c format, as it makes it easier for
> > the folks who apply the patches to do so.
>
> That's not just a suggestion ... patches that aren't in diff -c (or at
> least diff -u) format will be rejected
Title: Message
Eek.
Casting both to varchar makes it super quick so I'll
fix up the tables.
Added to the list of things to check for next
time...
On a
side note - I tried it with 7.4.1 on another box and it handled it
ok.
Thanks again :)
Chris.
-Original Message-From
