[EMAIL PROTECTED] writes:
> P.S. Sorry this is so long, but I wanted to include as much info as possible.
Throw in the non-commented lines in postgresql.conf; that would more
than likely make numeric answers possible, for some of it. If the
config is "out-of-the-box," then it's pretty likely that some
significant improvements can be gotten from modifying a few of the
config parameters. Increasing buffers would probably help query
speed, and if you're getting too many dead tuples, increasing the free
space map would make it possible for more to vacuum out.
Beyond that, you might want to grab the code for pg_autovacuum, and
drop that into place, as that would do periodic ANALYZEs that would
probably improve the quality of your selects somewhat. (It's in the
7.4 code "contrib" base, but works fine with 7.3.)
I think you might also get some significant improvements out of
changing the way you load the properties. If you set up a schema that
is suitably "permissive," and write a script that massages it a
little, COPY should do the trick to load the data in, which should be
helpful to the load process. If the data comes in a little more
intelligently (which might well involve some parts of the process
"dumbing down" :-)), you might take advantage of COPY and perhaps
other things (we see through the glass darkly).
I would think it also begs the question of whether or not you _truly_
need the "vacuum full." Are you _certain_ you need that? I would
think it likely that running "vacuum analyze" (and perhaps doing it a
little bit, continuously, during the load, via pg_autovacuum) would
likely suffice. Have you special reason to think otherwise?
output = ("cbbrowne" "@" "libertyrms.info")
(416) 646 3304 x124 (land)
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]