> > It appears that PostgreSQL is two to three times slower
> than MySQL.
> > For example, some pages that have some 30,000 characters
> (when saved
> > as HTML) take 1 to 1 1/2 seconds with MySQL but 3 to 4 seconds with
> > PostgreSQL. I had read that the former was generally
> faster than
>From: "Jeffrey W. Baker" <[EMAIL PROTECTED]>
>Sent: Sep 29, 2005 12:27 AM
>To: Ron Peacetree <[EMAIL PROTECTED]>
>Cc: pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org
>Subject: Re: [HACKERS] [PERFORM] A Better External Sort?
>
>You are engaging in a length and verbose exercise in men
On Wed, 28 Sep 2005, Joe wrote:
> Before I post the EXPLAIN and the table schema I'd appreciate
> confirmation that this list is the appropriate forum.
It is and and useful things to show are
* the slow query
* EXPLAIN ANALYZE of the query
* the output of \d for each table involved in the qu
On Wed, 2005-09-28 at 12:03 -0400, Ron Peacetree wrote:
> >From: "Jeffrey W. Baker" <[EMAIL PROTECTED]>
> >Perhaps I believe this because you can now buy as much sequential I/O
> >as you want. Random I/O is the only real savings.
> >
> 1= No, you can not "buy as much sequential IO as you want". E
On Wed, 2005-09-28 at 12:03 -0400, Ron Peacetree wrote:
> >From: "Jeffrey W. Baker" <[EMAIL PROTECTED]>
> >Sent: Sep 27, 2005 1:26 PM
> >To: Ron Peacetree <[EMAIL PROTECTED]>
> >Subject: Re: [HACKERS] [PERFORM] A Better External Sort?
> >
> >On Tue, 2005-09-27 at 13:15 -0400, Ron Peacetree wrote:
>
On Wed, 28 Sep 2005, Joe wrote:
> I'm converting a relatively small database (2 MB) from MySQL to PostgreSQL.
> It
> is used to generate web pages using PHP. Although the actual website runs
> under
> Linux, the development is done under XP. I've completed most of the data
> conversion and re
I'm converting a relatively small database (2 MB) from MySQL to PostgreSQL. It
is used to generate web pages using PHP. Although the actual website runs under
Linux, the development is done under XP. I've completed most of the data
conversion and rewrite of the PHP scripts, so now I'm compari
On Thu, 29 Sep 2005, Rajesh Kumar Mallah wrote:
> On 9/29/05, Gavin Sherry <[EMAIL PROTECTED]> wrote:
> > On Wed, 28 Sep 2005, Rajesh Kumar Mallah wrote:
> >
> > > > > Number of Copies | Update perl Sec
> > > > >
> > > > > 1 --> 119
> > > > > 2 ---> 59
> > > > > 3 ---> 38
> > > > > 4 ---> 28
On 9/29/05, Gavin Sherry <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Sep 2005, Rajesh Kumar Mallah wrote:
>
> > > > Number of Copies | Update perl Sec
> > > >
> > > > 1 --> 119
> > > > 2 ---> 59
> > > > 3 ---> 38
> > > > 4 ---> 28
> > > > 5 --> 22
> > > > 6 --> 19
> > > > 7 --> 16
> > > > 8 --> 14
If I've done this correctly, there should not be anywhere near
the number of context switches we currently see while sorting.
Each unscheduled context switch represents something unexpected
occuring or things not being where they are needed when they are
needed. Reducing such circumstances to the
In the interest of efficiency and "not reinventing the wheel", does anyone know
where I can find C or C++ source code for a Btree variant with the following
properties:
A= Data elements (RIDs) are only stored in the leaves, Keys (actually
KeyPrefixes; see "D" below) and Node pointers are only stor
>From: Matthew Nuzum <[EMAIL PROTECTED]>
>Sent: Sep 28, 2005 4:02 PM
>Subject: [PERFORM] Logarithmic change (decrease) in performance
>
Small nit-pick: A "logarithmic decrease" in performance would be
a relatively good thing, being better than either a linear or
exponential decrease in performance
On Wed, 28 Sep 2005, Rajesh Kumar Mallah wrote:
> > > Number of Copies | Update perl Sec
> > >
> > > 1 --> 119
> > > 2 ---> 59
> > > 3 ---> 38
> > > 4 ---> 28
> > > 5 --> 22
> > > 6 --> 19
> > > 7 --> 16
> > > 8 --> 14
> > > 9 --> 11
> > > 10 --> 11
> > > 11 --> 10
> >
> > So, 11 instances re
On 28 Sep 2005, at 15:32, Arnau wrote:
Hi all,
I have been "googling" a bit searching info about a way to
monitor postgresql (CPU & Memory, num processes, ... ) and I
haven't found anything relevant. I'm using munin to monitor others
parameters of my servers and I'd like to include po
Something interesting is going on. I wish I could show you the graphs,
but I'm sure this will not be a surprise to the seasoned veterans.
A particular application server I have has been running for over a
year now. I've been logging cpu load since mid-april.
It took 8 months or more to fall from
On 9/28/05, Arnau <[EMAIL PROTECTED]> wrote:
> Hi all,
>
>I have been "googling" a bit searching info about a way to monitor
> postgresql (CPU & Memory, num processes, ... ) and I haven't found
> anything relevant. I'm using munin to monitor others parameters of my
> servers and I'd like to inc
On 9/28/05, Gavin Sherry <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Sep 2005, Rajesh Kumar Mallah wrote:
>
> > Hi
> >
> > While doing some stress testing for updates in a small sized table
> > we found the following results. We are not too happy about the speed
> > of the updates particularly at high
On Sep 28, 2005, at 8:32 AM, Arnau wrote:
Hi all,
I have been "googling" a bit searching info about a way to
monitor postgresql (CPU & Memory, num processes, ... )
You didn't mention your platform, but I have an xterm open pretty
much continuously for my DB server that runs plain old t
>From: "Jeffrey W. Baker" <[EMAIL PROTECTED]>
>Sent: Sep 27, 2005 1:26 PM
>To: Ron Peacetree <[EMAIL PROTECTED]>
>Subject: Re: [HACKERS] [PERFORM] A Better External Sort?
>
>On Tue, 2005-09-27 at 13:15 -0400, Ron Peacetree wrote:
>
>>That Btree can be used to generate a physical reordering of the d
Hi all,
I have been "googling" a bit searching info about a way to monitor
postgresql (CPU & Memory, num processes, ... ) and I haven't found
anything relevant. I'm using munin to monitor others parameters of my
servers and I'd like to include postgresql or have a similar tool. Any
of you i
On Wed, 28 Sep 2005, Rajesh Kumar Mallah wrote:
> Hi
>
> While doing some stress testing for updates in a small sized table
> we found the following results. We are not too happy about the speed
> of the updates particularly at high concurrency (10 clients).
>
> Initially we get 119 updates / sec
Hi
While doing some stress testing for updates in a small sized table
we found the following results. We are not too happy about the speed
of the updates particularly at high concurrency (10 clients).
Initially we get 119 updates / sec but it drops to 10 updates/sec
as concurrency is increased.
hi
setup:
postgresql 8.0.3 put on debian on dual xeon, 8GB ram, hardware raid.
database just after recreation from dump takes 15gigabytes.
after some time (up to 3 weeks) it gets really slow and has to be dump'ed and restored.
as for fsm:
end of vacuum info:
INFO: free space map: 248 relations,
23 matches
Mail list logo
