On Fri, 15 Jan 2010, Greg Smith wrote:
It seems to me that CFQ is simply bandwidth limited by the extra processing
it has to perform.
I'm curious what you are doing when you see this.
16 disc 15kRPM RAID0, when using fadvise with more than 100 simultaneous
8kB random requests. I sent an
Thanks You,
I changed the random_page_cost to 2 and the query plan has changed and
speeds up.
I will check the other queries but I think I will leave it at this
value.
Thank you again.
Kaloyan Iliev
Robert Haas wrote:
On Fri, Jan 8, 2010 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
yeah, the values are at the end. Sounds like your vacuum settings are
too non-aggresive. Generally this is the vacuum cost delay being too
high.
Of course, I have to ask: what's the down side?
Yes! You can run vacuum verbose against the regular old postgres
database (or just create one for
Matthew Wakeling wrote:
On Fri, 15 Jan 2010, Greg Smith wrote:
My theory has been that the extra processing it has to perform you
describe just doesn't matter in the context of a fast system where
physical I/O is always the bottleneck.
Basically, to an extent, that's right. However, when you
Carlo Stonebanks stonec.regis...@sympatico.ca wrote:
yeah, the values are at the end. Sounds like your vacuum
settings are too non-aggresive. Generally this is the vacuum
cost delay being too high.
Of course, I have to ask: what's the down side?
If you make it too aggressive, it could
Jeff Davis wrote:
On one side, we might finally be
able to use regular drives with their caches turned on safely, taking
advantage of the cache for other writes while doing the right thing with
the database writes.
That could be good news. What's your opinion on the practical
* A database that is of small to medium size (5 - 10 GB)?
* Around 10 clients that perform constant write operations to the database
(UPDATE/INSERT)
* Around 10 clients that occasionally read from the database
* Around 6000 tables in your database
* A problem with tuning it all
* Migration to
On Wed, Jan 20, 2010 at 3:03 PM, Carlo Stonebanks
stonec.regis...@sympatico.ca wrote:
Yes! You can run vacuum verbose against the regular old postgres
database (or just create one for testing with nothing in it) and
you'll still get the fsm usage numbers from that! So, no need to run
it
That doesn't sound right. The kernel having 10% of memory dirty doesn't mean
there's a queue you have to jump at all. You don't get into any queue until
the kernel initiates write-out which will be based on the usage counters --
basically a lru. fsync and cousins like sync_file_range and
Greg Stark wrote:
That doesn't sound right. The kernel having 10% of memory dirty
doesn't mean there's a queue you have to jump at all. You don't get
into any queue until the kernel initiates write-out which will be
based on the usage counters -- basically a lru. fsync and cousins like
10 matches
Mail list logo
