On Jan 4, 2011, at 8:48 AM, Merlin Moncure wrote:
> On Mon, Jan 3, 2011 at 9:13 PM, Greg Smith wrote:
>> Strange, John W wrote:
>>>
>>> Has anyone had a chance to recompile and try larger a larger blocksize
>>> than 8192 with pSQL 8.4.x?
>>
>> While I haven't done the actual experiment you're
Kevin Grittner wrote:
Two common causes for this are blocking and overloading the I/O
system at checkpoint. You might want to turn on logging of
checkpoints to see if this happens only during checkpoints. See this
page for techniques to look at blocking:
http://wiki.postgresql.org/wiki/Lock_M
On 01/05/2011 05:03 AM, Fernando Mertins wrote:
Hi there, this is my first post.
I have a PostgreSQL 8.3.6, compiled by Visual C++ build 1400 running on
Windows with virtual machine
What kind of VM host? where? what else is on the same host?
Your most likely cul
Test,
Sorry trying to fix why my email is getting formatted to bits when posting to
the list.
- John
-Original Message-
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Strange, John W
Sent: Tuesday, January 04, 2011 1:01 PM
To:
This has gotten a lot better with the 2.x drivers as well.
I'm completely aware of the FusionIO and it's advantages/disadvantages.. I'm
currently getting the following pgbench results but still only hitting the
array for about 800MB/sec, short of the 3GB/sec that it's capable of. This is
simpl
On Jan 4, 2011, at 8:48 AM, Merlin Moncure wrote:
>
> most flash drives, especially mlc flash, use huge blocks anyways on
> physical level. the numbers claimed here
> (http://www.fusionio.com/products/iodrive/) (141k write iops) are
> simply not believable without write buffering. i didn't se
Fernando Mertins wrote:
> I have a PostgreSQL 8.3.6
You should consider upgrading to the latest minor release:
http://www.postgresql.org/support/versioning
http://www.postgresql.org/docs/8.3/static/release.html
> My question is, this same query executes many times a day and many
> times
Hi there, this is my first post.
I have a PostgreSQL 8.3.6, compiled by Visual C++ build 1400 running on
Windows with virtual machine, 2 GB ram, and configured the postgresql.conf
file to log statements duration >= 500 ms.
And I have this query/log entry:
2011-01-03 23:06:29 BRT LOG: duration: 2
On Mon, Jan 3, 2011 at 9:13 PM, Greg Smith wrote:
> Strange, John W wrote:
>>
>> Has anyone had a chance to recompile and try larger a larger blocksize
>> than 8192 with pSQL 8.4.x?
>
> While I haven't done the actual experiment you're asking about, the problem
> working against you here is how WA
Florian Weimer writes:
> * Tom Lane:
>> ALTER ADD FOREIGN KEY must lock both tables to add triggers to them.
> But why is such a broad lock needed? If the table was created in the
> current transaction and is empty, the contents of the foreign key
> table should not matter.
It's not about conte
nextage Tech wrote:
How good are certmagic.com practice exams for PostgreSQL
exam? My friends told me they are pretty good and he has passed many
exams with their material. Let me know guys!
Well, since the PostgreSQL CE 8 Silver exam itself isn't very well
defined as an industry certifica
Jeff Janes wrote:
There are parameters governing how likely it is that bgwriter falls
behind in the first place, though.
http://www.postgresql.org/docs/9.0/static/runtime-config-resource.html
In particular bgwriter_lru_maxpages could be made bigger and/or
bgwriter_delay smaller.
Also, one
* Tom Lane:
>> Do you mean that the ALTER query and subsequent queries are shown as
>> "waiting" in pg_stat_activity? In this case, I'm also wondering why
>> this is inecessary.
>
> ALTER ADD FOREIGN KEY must lock both tables to add triggers to them.
But why is such a broad lock needed? If the
13 matches
Mail list logo
