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
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 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
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 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 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
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
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
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
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 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:
> 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?
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
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
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 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 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 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 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 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: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 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
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
23 matches
Mail list logo
