[EMAIL PROTECTED] wrote:
I have been talking about two types of problems which are both based on
PostgreSQL's behavior with frequently updated tables.
Summary table: In the single row table system, you have to vacuum very
requently, and this affects performance.
Frequently updated tables: think abo
> [EMAIL PROTECTED] wrote:
>
>>
>>I have been talking about two types of problems which are both based on
>>PostgreSQL's behavior with frequently updated tables.
>>
>>Summary table: In the single row table system, you have to vacuum very
>>requently, and this affects performance.
>>
>>Frequently up
"Mohawksoft":
> I don't think anyone who has seriously looked at these issues has
> concluded that PostgreSQL works fine in these cases. The question is what,
> if anything, can be done? The frequent update issue really affects
> PostgreSQL's acceptance in web applications, and one which MySQL see
> On Wed, Jun 09, 2004 at 13:41:27 -0400,
> [EMAIL PROTECTED] wrote:
>>
>> Sigh, because vacuums take away from performance. Imagine a table that
>> has
>> to be updated on the order of a few thousand times a minute. Think about
>> the drop in performance during the vacuum.
>>
>> On a one row tab
On Tue, Jun 08, 2004 at 07:16:45PM -0400, [EMAIL PROTECTED] wrote:
> >
> >
> > [EMAIL PROTECTED] wrote:
> >
> >>I've been down several roads about how to handle data that has to change
> >>on a very frequent and rapid manner.
> >>
> >>Think about summary tables, WEB session tables, etc. As great as
On Wed, Jun 09, 2004 at 01:41:27PM -0400, [EMAIL PROTECTED] wrote:
> > On Wed, Jun 09, 2004 at 10:49:20PM +0800, Christopher Kings-Lynne wrote:
> > Also he said that the problem was solved with enough lazy VACUUM
> > scheduling. I don't understand why he doesn't want to use that
> > solution.
>
On Wed, 2004-06-09 at 11:41, [EMAIL PROTECTED] wrote:
> > On Wed, Jun 09, 2004 at 10:49:20PM +0800, Christopher Kings-Lynne wrote:
> >> >I love PG, I've been using it since version 6x, and it has gotten
> >> >fantastic over the years, and in many cases, I would choose it over
> >> >Oracle, but for
Sigh, because vacuums take away from performance.
This is a known issue that has been pretty much resolved for 7.5. Vacuum
in 7.5 does not take even close to as much IO resources.
Imagine a table that has
to be updated on the order of a few thousand times a minute. Think about
the drop in perfo
Also he said that the problem was solved with enough lazy VACUUM
scheduling. I don't understand why he doesn't want to use that
solution.
Because even lazy VACUUM is horrendous to performance but as I said in
a further post this has been pretty much fixed by (Jan I believe) in 7.5.
Sincerely,
Jos
On Wed, Jun 09, 2004 at 13:41:27 -0400,
[EMAIL PROTECTED] wrote:
>
> Sigh, because vacuums take away from performance. Imagine a table that has
> to be updated on the order of a few thousand times a minute. Think about
> the drop in performance during the vacuum.
>
> On a one row table, vacuum
> On Wed, Jun 09, 2004 at 10:49:20PM +0800, Christopher Kings-Lynne wrote:
>> >I love PG, I've been using it since version 6x, and it has gotten
>> >fantastic over the years, and in many cases, I would choose it over
>> >Oracle, but for systems that need frequent updates, I have a lot of
>> >concer
On Wed, Jun 09, 2004 at 10:49:20PM +0800, Christopher Kings-Lynne wrote:
> >I love PG, I've been using it since version 6x, and it has gotten
> >fantastic over the years, and in many cases, I would choose it over
> >Oracle, but for systems that need frequent updates, I have a lot of
> >concerns.
>
I love PG, I've been using it since version 6x, and it has gotten
fantastic over the years, and in many cases, I would choose it over
Oracle, but for systems that need frequent updates, I have a lot of
concerns.
...that's the price you pay for concurrency man...
Chris
---(en
>> I love PG, I've been using it since version 6x, and it has gotten
>> fantastic over the years, and in many cases, I would choose it over
>> Oracle, but for systems that need frequent updates, I have a lot of
>> concerns.
>
> ...that's the price you pay for concurrency man...
I think that's a co
>
> [EMAIL PROTECTED] wrote:
>
>>The best phrasing would be "the accumulating overhead of deletes and
>>updates."
>>
>>Yes.
>>
>>
>
> Are you using 7.3?
>
> I am asking because in 7.3 high update / delete tables could suffer
> (index and toast) bloat that was untamable via (lazy) VACUUM and FSM.
>
[EMAIL PROTECTED] wrote:
The best phrasing would be "the accumulating overhead of deletes and
updates."
Yes.
Are you using 7.3?
I am asking because in 7.3 high update / delete tables could suffer
(index and toast) bloat that was untamable via (lazy) VACUUM and FSM.
I believe this is fixed in 7.
>
>
> [EMAIL PROTECTED] wrote:
>
>>I've been down several roads about how to handle data that has to change
>>on a very frequent and rapid manner.
>>
>>Think about summary tables, WEB session tables, etc. As great as MVCC is
>>for the vast majority of uses. The overhead of updates and deletes can
>
[EMAIL PROTECTED] wrote:
I've been down several roads about how to handle data that has to change
on a very frequent and rapid manner.
Think about summary tables, WEB session tables, etc. As great as MVCC is
for the vast majority of uses. The overhead of updates and deletes can
kill a project that
18 matches
Mail list logo
