David Garamond <[EMAIL PROTECTED]> writes:
> Greg Stark wrote:
> >>Actually, each record will be incremented probably only thousands of times a
> >>day. But there are many banners. Each record has a (bannerid, campaignid,
> >>websiteid, date, countrycode) "dimensions" and (impression, click) "meas
On Mon, 24 May 2004, David Garamond wrote:
> Manfred Koizar wrote:
> > You mean InnoDB cannot handle the load?
>
> Perhaps it's more appropriate to say that the disk becomes the bottleneck.
Was this attempting to do each update in a separate transaction?
If so, that is certainly expected, with w
Greg Stark wrote:
Actually, each record will be incremented probably only thousands of times a
day. But there are many banners. Each record has a (bannerid, campaignid,
websiteid, date, countrycode) "dimensions" and (impression, click) "measures".
In the past when I had a very similar situation we
Manfred Koizar wrote:
You mean InnoDB cannot handle the load?
Perhaps it's more appropriate to say that the disk becomes the bottleneck.
--
dave
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscri
David Garamond <[EMAIL PROTECTED]> writes:
> Actually, each record will be incremented probably only thousands of times a
> day. But there are many banners. Each record has a (bannerid, campaignid,
> websiteid, date, countrycode) "dimensions" and (impression, click) "measures".
In the past when
Manfred Koizar <[EMAIL PROTECTED]> writes:
> On Sun, 23 May 2004 23:32:48 +0700, David Garamond
> <[EMAIL PROTECTED]> wrote:
>> I'm contemplating of moving to Postgres, but am worried with the MVCC
>> thing. I've previously tried briefly using InnoDB in MySQL but have to
>> revert back to MyISAM
On Sun, 23 May 2004 23:32:48 +0700, David Garamond
<[EMAIL PROTECTED]> wrote:
>Actually, each record will be incremented probably only thousands of
>times a day. But there are many banners. Each record has a (bannerid,
>campaignid, websiteid, date, countrycode) "dimensions" and (impression,
>cli
Manfred Koizar wrote:
begin;
update t set val=val+1; -- 1000 times
commit;
How many record versions does it create? 1 or 1000?
1000
I'm implementing a
banner counter which is incremented at least 2-3 millions a day.
How many rows? I would VACUUM that table after every few hundred
updates or whene
David Garamond <[EMAIL PROTECTED]> writes:
> begin;
> update t set val=val+1; -- 1000 times
> commit;
> How many record versions does it create? 1 or 1000?
1000.
> I'm implementing a
> banner counter which is incremented at least 2-3 millions a day. I
> thought I'd cheat by only commiting afte
On Sun, May 23, 2004 at 02:44:31 +0700,
David Garamond <[EMAIL PROTECTED]> wrote:
> begin;
> update t set val=val+1; -- 1000 times
> commit;
>
> How many record versions does it create? 1 or 1000? I'm implementing a
> banner counter which is incremented at least 2-3 millions a day. I
> thought
begin;
update t set val=val+1; -- 1000 times
commit;
How many record versions does it create? 1 or 1000? I'm implementing a
banner counter which is incremented at least 2-3 millions a day. I
thought I'd cheat by only commiting after every few minutes. Would that
work or would I still create as m
11 matches
Mail list logo
