Hi Wales
2012/2/27 Wales Wang wrote:
> There are many approach for PostgreSQL in-memory.
> The quick and easy way is making slave pgsql run on persistent RAM
> filesystem, the slave is part of master/slave replication cluster.
>
> The fstab and script make RAM file system persistent is below:
> S
On Tue, Feb 28, 2012 at 5:30 AM, Stefan Keller wrote:
>
> But what I'm finally after is a solution, where records don't get
> pushed back to disk a.s.a.p. but rather got hold in memory as long as
> possible assuming that there is enough memory.
fsync = off ?
--
Sent via pgsql-performance mailin
On 28 Únor 2012, 14:08, Claudio Freire wrote:
> On Tue, Feb 28, 2012 at 5:30 AM, Stefan Keller wrote:
>>
>> But what I'm finally after is a solution, where records don't get
>> pushed back to disk a.s.a.p. but rather got hold in memory as long as
>> possible assuming that there is enough memory.
>
On Tue, Feb 28, 2012 at 10:38 AM, Tomas Vondra wrote:
> On 28 Únor 2012, 14:08, Claudio Freire wrote:
>> On Tue, Feb 28, 2012 at 5:30 AM, Stefan Keller wrote:
>>>
>>> But what I'm finally after is a solution, where records don't get
>>> pushed back to disk a.s.a.p. but rather got hold in memory a
On 28 Únor 2012, 14:52, Claudio Freire wrote:
> On Tue, Feb 28, 2012 at 10:38 AM, Tomas Vondra wrote:
>> On 28 Únor 2012, 14:08, Claudio Freire wrote:
>>> On Tue, Feb 28, 2012 at 5:30 AM, Stefan Keller
>>> wrote:
But what I'm finally after is a solution, where records don't get
pus
On Tue, Feb 28, 2012 at 11:15 AM, Tomas Vondra wrote:
> I haven't investigated why exactly the data are not cached initially, but
> none of the options that I can think of could be "fixed" by setting
> "fsync=off". That's something that influences writes (not read-only
> database) and I don't thin
On Tue, Feb 28, 2012 at 12:30 AM, Stefan Keller wrote:
>
> Thank you for the tipp.
> Making slave pgsql run on persistent RAM filesystem is surely at least
> a possibility which I'll try out.
>
> But what I'm finally after is a solution, where records don't get
> pushed back to disk a.s.a.p. but r
On 28 Únor 2012, 15:24, Claudio Freire wrote:
> On Tue, Feb 28, 2012 at 11:15 AM, Tomas Vondra wrote:
>> I haven't investigated why exactly the data are not cached initially,
>> but
>> none of the options that I can think of could be "fixed" by setting
>> "fsync=off". That's something that influen
On Tue, Feb 28, 2012 at 1:05 PM, Tomas Vondra wrote:
> On 28 Únor 2012, 15:24, Claudio Freire wrote:
>> It speeds a lot more than the initial load of data.
>>
>> Assuming the database is read-only, but not the filesystem (ie: it's
>> not a slave, in which case all this is moot, as you said, there
On 02/27/2012 12:08 AM, Reuven M. Lerner wrote:
Hi, everyone. I wanted to thank you again for your help on the huge
delete problem that I was experiencing.
After a lot of trial and error, we finally came to the conclusion that
deleting this much data in the time frame that they need, on
underpow
I happened to be looking in the PostgreSQL logs (8.4.10, x86_64,
ScientificLinux 6.1) and noticed that an app was doing some sorting
(group by, order by, index creation) that ended up on disk rather than
staying in memory.
So I enabled trace_sort and restarted the app.
What followed confused me.
I
Jon Nelson writes:
> The config shows 128MB for work_mem and 2GB for maintenance_work_mem.
> Why does PostgreSQL /sometimes/ use the globally-configured values and
> sometimes use the values that come from the connection?
You sure those log entries are all from the same process?
On Tue, Feb 28, 2012 at 1:28 PM, Tom Lane wrote:
> Jon Nelson writes:
>> The config shows 128MB for work_mem and 2GB for maintenance_work_mem.
>> Why does PostgreSQL /sometimes/ use the globally-configured values and
>> sometimes use the values that come from the connection?
>
> You sure those lo
Jon Nelson writes:
> On Tue, Feb 28, 2012 at 1:28 PM, Tom Lane wrote:
>> Jon Nelson writes:
>>> Why does PostgreSQL /sometimes/ use the globally-configured values and
>>> sometimes use the values that come from the connection?
>> You sure those log entries are all from the same process?
> If I
On Tue, Feb 28, 2012 at 2:51 PM, Tom Lane wrote:
> Jon Nelson writes:
>> On Tue, Feb 28, 2012 at 1:28 PM, Tom Lane wrote:
>>> Jon Nelson writes:
Why does PostgreSQL /sometimes/ use the globally-configured values and
sometimes use the values that come from the connection?
>
>>> You sur
Quoting Jon Nelson:
"""
The config shows 128MB for work_mem and 2GB for maintenance_work_mem.
Why does PostgreSQL /sometimes/ use the globally-configured values and
sometimes use the values that come from the connection?
Am I wrong in misunderstanding what 'session' variables are? I thought
that se
Jon Nelson writes:
> On Tue, Feb 28, 2012 at 2:51 PM, Tom Lane wrote:
>> Hmph ... does seem a bit weird. Â Can you turn on log_statements and
>> identify which operations aren't using the session values?
> I had log_min_duration_statement = 1000.
That's not really going to prove much, as you wo
On Tue, Feb 28, 2012 at 5:48 PM, Stefan Keller wrote:
> P.S. And yes, the database is aka 'read-only' and truncated and
> re-populated from scratch every night. fsync is off so I don't care
> about ACID. After the indexes on name, hstore and geometry are
> generated I do a VACUUM FULL FREEZE. The
On Tue, Feb 28, 2012 at 6:54 PM, Tom Lane wrote:
>
>> ... which is the ORM library (SQLAlchemy) doing a reflection of the
>> table(s) involved.
>
> Oh, there's an ORM involved? I'll bet a nickel it's doing something
> surprising, like not issuing your SET until much later than you thought.
I'd r
On Tue, Feb 28, 2012 at 4:46 PM, Claudio Freire wrote:
> On Tue, Feb 28, 2012 at 6:54 PM, Tom Lane wrote:
>>
>>> ... which is the ORM library (SQLAlchemy) doing a reflection of the
>>> table(s) involved.
>>
>> Oh, there's an ORM involved? I'll bet a nickel it's doing something
>> surprising, lik
On Tue, Feb 28, 2012 at 8:00 PM, Jon Nelson wrote:
> I cranked the logging /all/ the way up and isolated the server.
> I suspect that your theory is correct.
Another option, depending on your SQLA version, when connections are
sent back to the pool, I seem to remember they were reset. That would
2012/2/28 Claudio Freire :
> On Tue, Feb 28, 2012 at 5:48 PM, Stefan Keller wrote:
>> P.S. And yes, the database is aka 'read-only' and truncated and
>> re-populated from scratch every night. fsync is off so I don't care
>> about ACID. After the indexes on name, hstore and geometry are
>> generate
On Feb 29, 2012 1:44 AM, "Claudio Freire" wrote:
> Another option, depending on your SQLA version, when connections are
> sent back to the pool, I seem to remember they were reset. That would
> also reset the work_mem, you'd still see the same pid on PG logs, but
> it's not the same session.
Exce
23 matches
Mail list logo
