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
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
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
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
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 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
> 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
