At 18:30 09/04/01 -0700, Kyle VanderBeek wrote:
>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"
> > this can not be included into 7.1 as it's now in the final Release
> > 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).
Yes they are. INT8 is not a feature/type yet supported by the driver, hence
Infact the jdbc driver supports no array's at this time (as PostgreSQL &
SQL3 arrays are different beasts).
If it's worked in the past, then that was sheer luck.
>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.
Are you talking about the optimiser in the backend as there isn't one in
the jdbc driver.
>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.
Ok, ensure you are closing the large objects within JDBC. If you are then
this is a backend problem.
One thing to try is to commit the transaction a bit more often (if you are
running within a single transaction for all 40k objects). Committing the
transaction will force the backend to close all open large objects on that
>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?
Again not JDBC. Forwarding to the hackers list on this one. The naming
conventions were changed a lot in 7.1, and it was for more flexability.
In response to
pgsql-hackers by date
|Next:||From: Alessio Bragadini||Date: 2001-04-10 13:32:52|
|Subject: Re: AW: Truncation of char, varchar types|
|Previous:||From: Andrew McMillan||Date: 2001-04-10 12:04:20|
|Subject: Re: "--tuning" compile and runtime option (?)|
pgsql-patches by date
|Next:||From: Peter Eisentraut||Date: 2001-04-10 16:42:12|
|Subject: Re: debian stylesheets|
|Previous:||From: andrea gelmini||Date: 2001-04-10 10:09:36|
|Subject: debian stylesheets|