Re: JDBC int8 hack
От | Kyle VanderBeek |
---|---|
Тема | Re: JDBC int8 hack |
Дата | |
Msg-id | 20010409183056.G30314@yaga.com обсуждение исходный текст |
Ответ на | JDBC int8 hack (Kyle VanderBeek <kylev@yaga.com>) |
Ответы |
Large Object problems (was Re: JDBC int8 hack)
Re: Re: JDBC int8 hack |
Список | pgsql-patches |
On Thu, Apr 05, 2001 at 04:08:48AM -0400, Peter T Mount wrote: > Quoting Kyle VanderBeek <kylev@yaga.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
В списке pgsql-patches по дате отправления: