From: Rural Hunter <ruralhunter@gmail.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Julio Leyva <jcleyva@hotmail.com>
Cc: pgsql-admin@postgresql.org
Subject: Re: plsql gets "out of memory"
Date: Tue, 30 Aug 2011 09:29:56 +0800
Message-ID: <4E5C3D14.1060907@gmail.com> (raw)
In-Reply-To: <4E5B72980200002500040820@gw.wicourts.gov>
References: <4E5B8FF7.4040007@gmail.com>
<BAY154-W12A115156AED066911581DA1140@phx.gbl>
<4E5B9604.5070602@gmail.com>
<4E5B518002000025000407E5@gw.wicourts.gov>
<4E5BA3C0.7080909@gmail.com>
<4E5B67910200002500040805@gw.wicourts.gov>
<4E5BB423.6010303@gmail.com>
<4E5B72980200002500040820@gw.wicourts.gov>
Thank you. I didn't understand what 'vacuum freeze' actually does. I
will check the detail to see if it's good for my situation. and I will
also test the load by tcp connection. Thanks again for all your advices
and they are really very helpful to me!
δΊ 2011/8/30 0:06, Kevin Grittner ει:
> Rural Hunter<ruralhunter@gmail.com> wrote:
>> 2011/8/29 23:18, Kevin Grittner:
>
>>> I also recommend a VACUUM FREEZE ANALYZE on the database unless
>>> most of these rows will be deleted or updated before you run a
>>> billion database transactions. Otherwise you will get a painful
>>> "anti-wraparound" autovacuum on everything, probably at a time
>>> of heavy usage.
>> hmm....I will try to turn autovacuum off though I didn't see any
>> resource intension caused by it.
>
> Well, turning off autovacuum during a bulk load is probably a net
> gain if it's insert-only (i.e., no need to query just-loaded data to
> decide what to do with new rows); but that's not what I was getting
> at. Bulk loading 200 GB of data which is not going to be deleted or
> updated heavily is setting a performance time bomb without a VACUUM
> FREEZE. At some point, perhaps months later, it will be necessary
> to freeze the tuples to prevent data loss, and since this occurs
> based on a threshold of how many transaction IDs have been consumed,
> it is most likely to happen at peak OLTP loads, when it will be the
> biggest problem. A VACUUM FREEZE (and you might as well throw in
> ANALYZE while you're at it) will take care of that up front. As a
> side benefit it will keep SELECT statements from generating heavy
> *write* loads on the first access to tuples, and will perform other
> maintenance which will improve database performance.
>
> I just count the time for VACUUM FREEZE ANALYZE as part of the bulk
> load time required before letting in users.
>
>>> Network latency?
>
>> No, I do the import locally on the db server so the network
>> letency can be excluded.
>
> Hmm... I don't remember the details, but there was a problem at
> some point where Linux pipe connections could introduce significant
> latency, and you could get much better performance on a TCP
> connection through localhost. It might be worth a try. (Maybe
> someone else will remember the details.)
>
> -Kevin
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: ruralhunter@gmail.com, Kevin.Grittner@wicourts.gov, jcleyva@hotmail.com
Subject: Re: plsql gets "out of memory"
In-Reply-To: <4E5C3D14.1060907@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox