> > Hi everyone,
> > What is the best Linux flavor for server
> which runs postgres alone.
> > The postgres must handle greater number of database
> around 200+. Performance
> > on speed is the vital factor.
> > Is it FreeBSD, CentOS, Fedora, Redhat xxx??
I see nobody suggesting Solaris...
Hello everyone,
I'm using PostgreSQL 8.3.8 running on a server with 2 Xeon CPUs, 4GB
RAM, 4+2 disks in RAID 5 and CentOS 5.3. There's only one database
which dumped with pgdump takes ~0.5GB.
There are ~100 tables in the database and one of them (tableOne) always
contains only a single row.
In response to Michal Vitecek :
> There are ~100 tables in the database and one of them (tableOne) always
> contains only a single row. There's one index on it. However performing
In this case, only one row, you don't need an index. Really.
> update on the single row (which occurs every 60 sec
> I see nobody suggesting Solaris... ZFS is supposed to be a
> very nice FS...
(of course, it's not a linux flavor...)
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
There are ~100 tables in the database and one of them (tableOne) always
contains only a single row. There's one index on it. However performing
update on the single row (which occurs every 60 secs) takes a
considerably long time -- around 200ms. The system is not loaded in any
way.
How often is
On Thu, 1 Oct 2009, Greg Smith wrote:
On Thu, 1 Oct 2009, Matthew Wakeling wrote:
For comparison, with Red Hat, you will need to upgrade to a whole new
distribution whenever you want updated software, which is a much bigger
undertaking.
This is somewhat true for larger packages, but it's not
On Fri, 2009-10-02 at 12:39 +0100, Matthew Wakeling wrote:
> The reason we switched that machine to Debian was due to the
> postgresql-devel package being missing for Red Hat. We need that
> package in order to install some of our more interesting extensions. A
> quick look at http://yum.pgsqlrpms
On Fri, Oct 2, 2009 at 12:47 AM, alpesh gajbe wrote:
> We have a Proliant DL585 G5 with 16 cores and 32 GB Ram in the terms of
> processors we found that buying amd makes much more sense because in the
> same price we could put more processors
> on the machine and utilize the multiple cores effec
On Fri, Oct 2, 2009 at 4:18 AM, Michal Vitecek wrote:
> Hello everyone,
>
> I'm using PostgreSQL 8.3.8 running on a server with 2 Xeon CPUs, 4GB
> RAM, 4+2 disks in RAID 5 and CentOS 5.3. There's only one database
> which dumped with pgdump takes ~0.5GB.
>
> There are ~100 tables in the datab
Matthew Wakeling writes:
> The reason we switched that machine to Debian was due to the
> postgresql-devel package being missing for Red Hat. We need that package
> in order to install some of our more interesting extensions. A quick look
> at http://yum.pgsqlrpms.org/8.4/fedora/fedora-9-x86_64
On Fri, 2 Oct 2009, Tom Lane wrote:
Matthew Wakeling writes:
The reason we switched that machine to Debian was due to the
postgresql-devel package being missing for Red Hat. We need that package
in order to install some of our more interesting extensions. A quick look
at http://yum.pgsqlrpms.or
S Arvind wrote:
Hi everyone,
What is the best Linux flavor for server which runs postgres
alone. The postgres must handle greater number of database around
200+. Performance on speed is the vital factor.
Is it FreeBSD, CentOS, Fedora, Redhat xxx??
-Arvind S
We use Arch Linux and love it
On 10/02/2009 10:23 AM, Matthew Wakeling wrote:
On Fri, 2 Oct 2009, Tom Lane wrote:
You switched OSes instead of complaining to the repository maintainer
that he'd forgotten a subpackage? You must have a lot of time on your
hands.
Camel's back, straw.
Besides, both I and our sysadmin are muc
* Mark Mielke [091002 11:41]:
> ... until you move on and leave the company with some hacked up Debian
> installs that nobody knows how to manage.
Could be worse, they could leave a Redhat/CentOS box that *can't* be
managed
emacs anyone?
/duck and run, promising not to post on this again
On Thu, Oct 1, 2009 at 4:46 AM, S Arvind wrote:
> Hi everyone,
> What is the best Linux flavor for server which runs postgres alone.
> The postgres must handle greater number of database around 200+. Performance
> on speed is the vital factor.
> Is it FreeBSD, CentOS, Fedora, Redhat xxx??
F
On Fri, 2 Oct 2009, Matthew Wakeling wrote:
The reason we switched that machine to Debian was due to the
postgresql-devel package being missing for Red Hat. We need that package
in order to install some of our more interesting extensions. A quick
look at http://yum.pgsqlrpms.org/8.4/fedora/fed
On Thu, Oct 1, 2009 at 5:46 AM, S Arvind wrote:
> Hi everyone,
> What is the best Linux flavor for server which runs postgres alone.
> The postgres must handle greater number of database around 200+. Performance
> on speed is the vital factor.
> Is it FreeBSD, CentOS, Fedora, Redhat xxx??
I
On Fri, 2 Oct 2009, Jon Nelson wrote:
I personally prefer openSUSE (or SLES/SLED if you want their
commerical offering). I find it faster, more up-to-date (but no
"churn"), and in general higher quality - "it just works". I find
postgresql *substantially* faster on openSUSE than CentOS, but that
On Fri, Oct 2, 2009 at 9:54 AM, Merlin Moncure wrote:
> On Fri, Oct 2, 2009 at 4:18 AM, Michal Vitecek wrote:
>> Hello everyone,
>>
>> I'm using PostgreSQL 8.3.8 running on a server with 2 Xeon CPUs, 4GB
>> RAM, 4+2 disks in RAID 5 and CentOS 5.3. There's only one database
>> which dumped wit
On Fri, 2 Oct 2009, Merlin Moncure wrote:
I know I'm in the minority here, but I _always_ compile postgresql
myself directly from official sources. It's easy enough and you never
know when you have to do an emergency patch or cassert build, etc.
That requires one take all of the security upda
On Fri, Oct 2, 2009 at 1:39 PM, Robert Haas wrote:
> On Fri, Oct 2, 2009 at 9:54 AM, Merlin Moncure wrote:
>> it is ridiculous. your problem is almost definitely dead rows. I
>> can't recall (and I can't find the info anywhere) if the 'hot' feature
>> requires an index to be active -- I think i
Robert Haas wrote:
> On Fri, Oct 2, 2009 at 9:54 AM, Merlin Moncure wrote:
>> On Fri, Oct 2, 2009 at 4:18 AM, Michal Vitecek wrote:
>>> Hello everyone,
>>>
>>> I'm using PostgreSQL 8.3.8 running on a server with 2 Xeon CPUs, 4GB
>>> RAM, 4+2 disks in RAID 5 and CentOS 5.3. There's only one dat
Merlin Moncure wrote:
> I know I'm in the minority here, but I _always_ compile postgresql
> myself directly from official sources. It's easy enough and you
> never know when you have to do an emergency patch or cassert build,
> etc.
A minority, perhaps; but I'm there with you. ;-)
-Kevin
On 10/02/2009 01:20 PM, Merlin Moncure wrote:
I know I'm in the minority here, but I _always_ compile postgresql
myself directly from official sources. It's easy enough and you never
know when you have to do an emergency patch or cassert build, etc.
+1
I decided to do this as soon as I fi
On Thu, Oct 1, 2009 at 4:11 AM, S Arvind wrote:
> In some docs i read that shared buffer must be increased based on the
> maximum dataset size. For my scenario the dataset size is relative small
> less then a Gb, but database# handled by a server is nearly 200db per
> server and average connectio
Tom Lane wrote:
> As of 8.4, the typical case is that an open transaction blocks
> deletion of rows that were deleted since the transaction's current
> *statement* started. So this makes a huge difference if you have
> long-running transactions that consist of a series of not-so-long
> stateme
Greg Smith writes:
> The trick I suggest people who use packaged builds get familiar with is
> knowing that if you run pg_config and look for the CONFIGURE line, you'll
> find out exactly what options were used by the builder of the package you
> have, when they compiled the server from source
Tom Lane writes:
> It's worth your time to learn how to do this on whatever system you
> prefer to use. Then, if you're ever in a situation where you really
> need patch XYZ right now, you can easily add that patch to the package
> sources and rebuild a custom version that will play nicely within
"Kevin Grittner" writes:
> Tom Lane wrote:
>> As of 8.4, the typical case is that an open transaction blocks
>> deletion of rows that were deleted since the transaction's current
>> *statement* started.
[ BTW, of course that should have read "blocks removal of" ... ]
> Surely the original ver
[I got no response on -general for a few days so I'm trying here]
When we upgraded from linux-2.6.24 to linux-2.6.27, our pg_dump
duration increased by 20% from 5 hours to 6. My first attempt at
resolution was to boot with elevator=deadline. However that's
actually the default IO scheduler in bo
Justin Pryzby writes:
> When we upgraded from linux-2.6.24 to linux-2.6.27, our pg_dump
> duration increased by 20% from 5 hours to 6.
Wouldn't be the first time the kernel guys broke something :-(
I think a complaint to your kernel supplier is in order.
In a coincidence, the first item in the c
Thanks Robert,
So for our scenario what is the most important factor to be noted
for performance.
-Arvind S
On Sat, Oct 3, 2009 at 12:49 AM, Robert Haas wrote:
> On Thu, Oct 1, 2009 at 4:11 AM, S Arvind wrote:
> > In some docs i read that shared buffer must be increased based on the
32 matches
Mail list logo
