Hello,
Wondering what's a good value for effective_io_concurrency when dealing with
FusionIO drives...anyone have any experience with this?
I know that SSDs vary from 10 channels to 30, and that 1 SSD about as fast as a
4-drive RAID, but I can't seem to settle on a good value to use for
effect
On Thu, Mar 25, 2010 at 10:00 PM, Merlin Moncure wrote:
> On Tue, Mar 23, 2010 at 5:00 PM, Eliot Gable
> >
> wrote:
> > The complex type contains roughly 25 fields, mostly text, plus another 10
> > REFCURSORs.
>
> How many rows min/max/avg are coming back in your refcursors? Are you
> using curs
Hi Pierre,
First of all , I Thank all for sharing the information on this Issue.
On Thu, Mar 25, 2010 at 11:44 PM, Pierre C wrote:
>
> If you do large transactions, which emits large quantities of xlog, be
> aware that while the previous xlog segment is being fsynced, no new writes
> happen to
On Tue, Mar 23, 2010 at 5:00 PM, Eliot Gable
wrote:
> The complex type contains roughly 25 fields, mostly text, plus another 10
> REFCURSORs.
How many rows min/max/avg are coming back in your refcursors? Are you
using cursors in order to return multiple complex data structures
(sets, etc) in a s
Scott Marlowe wrote:
On Thu, Mar 25, 2010 at 2:29 PM, Pierre C wrote:
Hannu Krosing wrote:
Pulling the plug should not corrupt a postgreSQL database, unless it was
using disks which lie about write caching.
Didn't we recently put the old wife's 'the disks lied' tale to bed
Hi everyone,
I've been trying to reduce both memory usage and runtime for a query.
Comments/suggestions gratefully received. Details are at
http://bulldog.duhs.duke.edu/~faheem/snppy/opt.pdf
See particularly Section 1 - Background and Discussion.
If you want a text version, see
http://bull
On Thu, Mar 25, 2010 at 2:29 PM, Pierre C wrote:
>> Hannu Krosing wrote:
>>>
>>> Pulling the plug should not corrupt a postgreSQL database, unless it was
>>> using disks which lie about write caching.
>>>
>> Didn't we recently put the old wife's 'the disks lied' tale to bed in
>> favour of actuall
Hannu Krosing wrote:
Pulling the plug should not corrupt a postgreSQL database, unless it was
using disks which lie about write caching.
Didn't we recently put the old wife's 'the disks lied' tale to bed in
favour of actually admiting that some well known filesystems and
saftware raid system
On Thu, Mar 25, 2010 at 2:04 PM, James Mansion
wrote:
> Hannu Krosing wrote:
>>
>> Pulling the plug should not corrupt a postgreSQL database, unless it was
>> using disks which lie about write caching.
>>
>
> Didn't we recently put the old wife's 'the disks lied' tale to bed in favour
> of actuall
Hannu Krosing wrote:
Pulling the plug should not corrupt a postgreSQL database, unless it was
using disks which lie about write caching.
Didn't we recently put the old wife's 'the disks lied' tale to bed in
favour of actually admiting that some well known filesystems and
saftware raid system
On Wed, 2010-03-24 at 09:55 +0100, Yeb Havinga wrote:
> Greg Smith wrote:
> > Tom Lane wrote:
> >> So has anyone looked at porting MythTV to PG?
> >>
> >
> > Periodically someone hacks together something that works, last big
> > effort I'm aware of was in 2006, and then it bit rots away. I'm s
Hi All,
We have a postgres database in which couple of tables get bloated due to
heavy inserts and deletes. Auto vacuum is running. My question is how
can I make auto vacuum more aggressive? I am thinking of enabling
autovacuum_vacuum_cost_delay and autovacuum_vacuum_cost_limit
parameters. Can
If you do large transactions, which emits large quantities of xlog, be
aware that while the previous xlog segment is being fsynced, no new writes
happen to the next segment. If you use large wal_buffers (more than 16 MB)
these buffers can absorb xlog data while the previous segment is being
On Thu, Mar 25, 2010 at 11:01 AM, Tadipathri Raghu wrote:
> Hi All,
>
> Can anybody clarify on this, why wal_buffer is 64kb and what is advantages
> and disadvantages in increasing or decreasing the wal_buffer.
>
is 64kb just because by default we have low values in almost everything :)
and the a
On Thu, 2010-03-25 at 20:31 +0530, Tadipathri Raghu wrote:
> Hi All,
>
> Can anybody clarify on this, why wal_buffer is 64kb and what is
> advantages and disadvantages in increasing or decreasing the
> wal_buffer.
This is addressed in the documentation.
http://www.postgresql.org/docs/8.4/intera
On Mon, Mar 22, 2010 at 6:19 PM, Carlo Stonebanks
wrote:
> Thanks for the insight. How much more of a server's resources will be
> consumed by an ANALYZE with default_statistics_target = 100?
I don't think it will be much of a problem, especially since
autovacuum will do only the tables that need
Hi All,
Can anybody clarify on this, why wal_buffer is 64kb and what is advantages
and disadvantages in increasing or decreasing the wal_buffer.
Regards
Raghav
On Wed, 24 Mar 2010, Campbell, Lance wrote:
I have 24 Gig of memory on my server...
Our server manager seems to think that I have way to much memory. He
thinks that we only need 5 Gig.
You organisation probably spent more money getting your server manager to
investigate how much RAM you need
18 matches
Mail list logo
