Re: JDBC int8 hack

On Thu, Apr 05, 2001 at 04:08:48AM -0400, Peter T Mount wrote:
> Quoting Kyle VanderBeek <kylev(at)yaga(dot)com>:
>
>
> > Please consider applying my patch to the 7.0 codebase as a stop-gap
> > measure until such time as the optimizer can be improved to notice
> > indecies on INT8 columns and cast INT arguments up.
>
> This will have to wait until after 7.1 is released. As this is a "new" feature,
> this can not be included into 7.1 as it's now in the final Release Candidate
> phase.

This is a new feature? Using indecies is "new"? I guess I really beg to
differ. Seems like a bugfix to me (in the "workaround" category).

I'm going to start digging around in the optimizer code so such hacks as
mine aren't needed. It's really haenous to find out your production
server is freaking out and doing sequential scans for EVERYTHING.

Another hack I need to work on (or someone else can) is to squish in a
layer of filesystem hashing for large objects. We tried to use large
objects and got destroyed. 40,000 rows and the server barely functioned.
I think this is because of 2 things:

1) Filehandles not being closed. This was an oversite I've seen covered
in the list archives somewhere.

2) The fact that all objects are stored in a the single data directory.
Once you get up to a good number of objects, directory scans really take a
long, long time. This slows down any subsequent openings of large
objects. Is someone working on this problem? Or have a patch already?

--
Kyle.
"I hate every ape I see, from chimpan-A to chimpan-Z" -- Troy McClure