On Sun, Apr 21, 2013 at 5:46 AM, sunil virmani wrote:
> My DB version is little old - 8.1.18.
>
Your db is exceptionally old and very much unsupported. Vacuum has
massively improved since 8.1 .
See http://www.postgresql.org/support/versioning/ regarding supported
versions.
32 bit pg should not matter.
Shared buffers and similar variables will be another matter.
Why the heck are you running 32 bit pg on a 64 bit system? You are
almost certainly doing it wrong.
--
Rob Wultsch
wult...@gmail.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresq
t/versioning/
--
Rob Wultsch
wult...@gmail.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
flip bits and postgres does not checksum data,
so it will not automatically detect corruption for you. I would steer
well clear of SATA unless you are going to be using a fs like ZFS
which checksums data. I would hope that a SAN would detect this for
you, but I have no idea.
--
Rob Wultsch
wult...
L. Using a crash unsafe product will yield undesirable
results when a server crashes. It is also faster for many use cases.
InnoDB is crash safe. It is just that simple.
--
Rob Wultsch
wult...@gmail.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to y
e an idea that
> avoids the problems that have been observed with other hint systems,
> that could lead to valuable discussion.
>
> That seems to me to characterize the nuance.
Where exactly are the problems with other systems noted? Most other
systems have this option so saying &quo
have a raid card? Is it properly configured?
--
Rob Wultsch
wult...@gmail.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
rmance when using commit_delay compared to the default.
>
> Anyway I would recommended right now to stick with the default and
> not really use it. It does the sync absorbtion well if you have two
> many users (though not perfect).
Sounds like this setting should go away unless there is
removed?
--
Rob Wultsch
wult...@gmail.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On Wed, Oct 27, 2010 at 6:55 PM, Robert Haas wrote:
> On Wed, Oct 27, 2010 at 12:41 AM, Rob Wultsch wrote:
>> On Tue, Oct 26, 2010 at 7:25 AM, Robert Haas wrote:
>>> On Tue, Oct 26, 2010 at 10:13 AM, Rob Wultsch wrote:
>>>> The double write buffer is one of the fe
On Tue, Oct 26, 2010 at 7:25 AM, Robert Haas wrote:
> On Tue, Oct 26, 2010 at 10:13 AM, Rob Wultsch wrote:
>> The double write buffer is one of the few areas where InnoDB does more
>> IO (in the form of fsynch's) than PG. InnoDB also has fuzzy
>> checkpoints (which h
On Tue, Oct 26, 2010 at 5:41 AM, Robert Haas wrote:
> On Fri, Oct 22, 2010 at 3:05 PM, Kevin Grittner
> wrote:
>> Rob Wultsch wrote:
>>
>>> I would think full_page_writes=off + double write buffer should be
>>> far superior, particularly given that the WA
On Fri, Oct 22, 2010 at 1:15 PM, Kevin Grittner
wrote:
> Rob Wultsch wrote:
>
>> not needing full_page_writes would make geographically dispersed
>> replication possible for certain cases where it is not currently
>> (or at least rather painful).
>
> Do you have any
On Fri, Oct 22, 2010 at 12:05 PM, Kevin Grittner
wrote:
> Rob Wultsch wrote:
>
>> I would think full_page_writes=off + double write buffer should be
>> far superior, particularly given that the WAL is shipped over the
>> network to slaves.
>
> For a reasonably brie
On Fri, Oct 22, 2010 at 10:28 AM, Kevin Grittner
wrote:
> Rob Wultsch wrote:
>
>> has PG considered using a double write buffer similar to InnodB?
>
> That seems inferior to the full_page_writes strategy, where you only
> write a page twice the first time it is writt
most obvious
> example where the atomic write implementation seems to always make disabling
> full_page_writes safe.
>
For the sake of argument, has PG considered using a double write
buffer similar to InnodB?
--
Rob Wultsch
wult...@gmail.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
ing a drop down menu for other version of the
manual for a page. I have not had time to write a patch, but I think it is
something that MySQL does better that pg.
As an example take a look at the page on select for MySQL:
http://dev.mysql.com/doc/refman/5.1/en/select.html .
If you want a earlier or later version they are easily accessible via a link
on the left.
--
Rob Wultsch
wult...@gmail.com
gt; Header)
> GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431 2EB0 389D 1DC2 3172 0C99
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
That is not true eit
ted the issue.
>>
>>
>>
>> create table test_time (time timestamp);
>>
>> delete from test_time;
>>
>> insert into test_time select now();
>
>
> Use timeofday() instead, now() returns the transaction starting time.
Is this part of the SQL
the crappy box lied about
fsync'ing data and your server is not. Did you purchase a raid card
with a bbu? If so, can you set the write cache policy to write-back?
--
Rob Wultsch
wult...@gmail.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
e? Wouldn't a global temporary table have content that is not
visible between db connections? A db session many not be the same as a
user session.
--
Rob Wultsch
wult...@gmail.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
ql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
I think it would be interesting to create a ram disk and insert into
it. In the MySQL community even thought MyISAM has fallen out of use
the Memory table (based on MyISAM) is still
On Tue, May 25, 2010 at 4:26 PM, David Jarvis wrote:
> shared_buffers = 1GB
> temp_buffers = 32MB
> work_mem = 32MB
> maintenance_work_mem = 64MB
> effective_cache_size = 256MB
Shouldn't effective_cache_size be significantly larger?
--
Rob Wultsch
wult...@gmail.com
On Wed, Mar 17, 2010 at 7:30 AM, Tom Lane wrote:
> Greg Smith writes:
>> Rob Wultsch wrote:
>>> At a minimum I assume that if both of the commands were started at
>>> about the same time they would each scan the table in the same
>>> direction and whichever cr
would benefit from most of
the table data it needed being prepopulated in shared buffers. Is this
the case?
--
Rob Wultsch
wult...@gmail.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
25 matches
Mail list logo
