On 22.04.2008, at 17:25, Scott Marlowe wrote:
On Tue, Apr 22, 2008 at 7:42 AM, Thomas Spreng <[EMAIL PROTECTED]>
wrote:
I think I'll upgrade PostgreSQL to the latest 8.3 version in the next
few days anyway, along with a memory upgrade (from 1.5GB to 4GB)
and a
new 2x RAID-1 (instead of RAID-
On Tue, Apr 22, 2008 at 7:42 AM, Thomas Spreng <[EMAIL PROTECTED]> wrote:
>
> I think I'll upgrade PostgreSQL to the latest 8.3 version in the next
> few days anyway, along with a memory upgrade (from 1.5GB to 4GB) and a
> new 2x RAID-1 (instead of RAID-5) disk configuration. I hope that this
>
On 19.04.2008, at 19:11, Christopher Browne wrote:
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Thomas
Spreng) wrote:
On 16.04.2008, at 17:42, Chris Browne wrote:
What I meant is if there are no INSERT's or UPDATE's going on it
shouldn't affect SELECT queries, or am I wrong?
that's correct, there are nightly (at least at the moment) processes that
insert around 2-3 mio rows and delete about the same amount. I can see
that
those 'checkpoints are occurring too frequently' messages are only logged
during that timeframe.
Perhaps you should increase the quantity of
On 19.04.2008, at 19:04, Scott Marlowe wrote:
No, that will certainly NOT just affect write performance; if the
postmaster is busy writing out checkpoints, that will block SELECT
queries that are accessing whatever is being checkpointed.
What I meant is if there are no INSERT's or UPDATE's go
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Thomas Spreng)
wrote:
> On 16.04.2008, at 17:42, Chris Browne wrote:
>> [EMAIL PROTECTED] (Thomas Spreng) writes:
>>> On 16.04.2008, at 01:24, PFC wrote:
> The queries in question (select's) occasionally take up to 5 mins
>
On Wed, Apr 16, 2008 at 3:48 PM, Thomas Spreng <[EMAIL PROTECTED]> wrote:
>
> On 16.04.2008, at 17:42, Chris Browne wrote:
>
> > [EMAIL PROTECTED] (Thomas Spreng) writes:
> >
> > > On 16.04.2008, at 01:24, PFC wrote:
> > >
> > > >
> > > >
> > > > > The queries in question (select's) occasionally t
On Wed, Apr 16, 2008 at 11:48:21PM +0200, Thomas Spreng wrote:
> What I meant is if there are no INSERT's or UPDATE's going on it
> shouldn't
> affect SELECT queries, or am I wrong?
CHECKPOINTs also happen on a time basis. They should be short in that case,
but they still have to happen.
--
On 16.04.2008, at 17:42, Chris Browne wrote:
[EMAIL PROTECTED] (Thomas Spreng) writes:
On 16.04.2008, at 01:24, PFC wrote:
The queries in question (select's) occasionally take up to 5 mins
even if they take ~2-3 sec under "normal" conditions, there are no
sequencial scans done in those queri
[EMAIL PROTECTED] (Thomas Spreng) writes:
> On 16.04.2008, at 01:24, PFC wrote:
>>
>>> The queries in question (select's) occasionally take up to 5 mins
>>> even if they take ~2-3 sec under "normal" conditions, there are no
>>> sequencial scans done in those queries. There are not many users
>>> co
On Wed, 16 Apr 2008 06:07:04 +0200, Thomas Spreng <[EMAIL PROTECTED]> wrote:
On 16.04.2008, at 01:24, PFC wrote:
The queries in question (select's) occasionally take up to 5 mins even
if they take ~2-3 sec under "normal" conditions, there are no
sequencial scans done in those queries. The
On 16.04.2008, at 01:24, PFC wrote:
The queries in question (select's) occasionally take up to 5 mins
even if they take ~2-3 sec under "normal" conditions, there are no
sequencial scans done in those queries. There are not many users
connected (around 3, maybe) to this database usually si
The queries in question (select's) occasionally take up to 5 mins even
if they take ~2-3 sec under "normal" conditions, there are no sequencial
scans done in those queries. There are not many users connected (around
3, maybe) to this database usually since it's still in a testing phase.
I
Hi everyone,
I have some serious performance problems on a database where some
queries take up to 100 (or even more) times longer occasionally. The
database itself consists of one bigger table (around 3.5GB in size and
around 2 mio rows, 4-5 additional indexes) and some really small tables.
14 matches
Mail list logo
