it did.. thanks.. generally a weeks process turned out to be less than a
day..
On Thursday 25 November 2004 15:06, Christopher Kings-Lynne wrote:
> > update SUBSCRIPTIONTABLE set ACTIVEFLAG='Y' where mobile_num in
> > (select
> > mobile_num from LOADED_MOBILE_NUMBERS)
>
> Change t
Gary Doades wrote:
How much RAM can a single postgres backend use?
I've just loaded a moderately sized dataset into postgres and was
applying RI constraints to the tables (using pgadmin on windows). Part
way though I noticed the (single) postgres backend had shot up to using
300+ MB of my RAM!
Oops
We have a network application in which many clients will be executing a mix of
select/insert/update/deletes on a central postgres 7.4.5 database, running on
Solaris 9 running on dual 2.3 ghz Xeons, with 2 gig of RAM and a RAID 10 disk.
The test database is about 400 meg in size.
We have tuned t
"David Parker" <[EMAIL PROTECTED]> writes:
> 1) Given that the data is all cached, what can we do to make sure that
> postgres is generating the most efficient plans in this case? We have
> bumped up effective_cache_size, but it had no effect.
If you're willing to bet on everything being in RAM al
Hi. Thanks for responding.
As it happens, the client-side already has a connection pool.
We need statistics enabled so that autovacuum can run (without
autovacuum running our updates begin to kill us pretty quickly).
Moving off of Solaris 9 isn't an option, even for the purposes of
comparison,
Gary Doades <[EMAIL PROTECTED]> writes:
> I've just loaded a moderately sized dataset into postgres and was
> applying RI constraints to the tables (using pgadmin on windows). Part
> way though I noticed the (single) postgres backend had shot up to using
> 300+ MB of my RAM!
> Since I can't get an
Tom Lane wrote:
It's also worth noting that work_mem is temporarily set to
maintenance_work_mem, which you didn't tell us the value of:
It's left at the default. (16384).
This would be OK if that is all it used for this type of thing.
My recollection is that hash join chooses hash table partitions