On Sun, Dec 04, 2005 at 18:28:53 +0100,
Tino Wildenhain <[EMAIL PROTECTED]> wrote:
> Am Sonntag, den 04.12.2005, 09:56 -0600 schrieb Bruno Wolff III:
> > On Sun, Dec 04, 2005 at 14:40:49 +0100,
> > Tino Wildenhain <[EMAIL PROTECTED]> wrote:
> > >
> > > Doing something to enable aggregates in g
Tino Wildenhain <[EMAIL PROTECTED]> writes:
> Am Sonntag, den 04.12.2005, 09:56 -0600 schrieb Bruno Wolff III:
> > On Sun, Dec 04, 2005 at 14:40:49 +0100,
> >
> > Assuming you are refering to max and min, this has already been done and is
> > in 8.1.
>
> I also mean sum, avg, ... and last not le
Am Sonntag, den 04.12.2005, 09:56 -0600 schrieb Bruno Wolff III:
> On Sun, Dec 04, 2005 at 14:40:49 +0100,
> Tino Wildenhain <[EMAIL PROTECTED]> wrote:
> >
> > Doing something to enable aggregates in general to use
> > an existent index would be a nice ide imho.
> > (With all the visibility hint
On Sun, Dec 04, 2005 at 14:40:49 +0100,
Tino Wildenhain <[EMAIL PROTECTED]> wrote:
>
> Doing something to enable aggregates in general to use
> an existent index would be a nice ide imho.
> (With all the visibility hinting in place)
Assuming you are refering to max and min, this has already bee
Am Sonntag, den 04.12.2005, 14:02 +0100 schrieb Guido Neitzer:
> On 02.12.2005, at 20:02 Uhr, Jaime Casanova wrote:
>
> > so the way to do it is create a trigger that record in a table the
> > number of rows...
>
> As there are SO MANY questions about the "count(*)" issue, I wonder
> whether it
On 02.12.2005, at 20:02 Uhr, Jaime Casanova wrote:
so the way to do it is create a trigger that record in a table the
number of rows...
As there are SO MANY questions about the "count(*)" issue, I wonder
whether it makes sense to add a mechanism which does exactly the
method mentioned abov
On 12/2/2005 2:02 PM, Jaime Casanova wrote:
so the way to do it is create a trigger that record in a table the
number of rows...
Neither, because now you have to update one single row in that new
table, which causes a row exclusive lock. That is worse than an
exclusive lock on the original ta
On 12/2/05, Poul Møller Hansen <[EMAIL PROTECTED]> wrote:
> Rodrigo Gonzalez wrote:
> > I answer here so each one can help you.
> >
> > Cannot understand what you meanindex is numbered? Are you talking
> > about "autoincrement" as called in mysql? use sequences please
> >
>
> Sorry, forgot that
No problem at all.
MyISAM stores the row count in it's header (.frm file).
You can do something like this using a table that has for example
tablename, rowcount.
On the other hand, MySQL with MyISAM does not have row locking, so this
problem is not considered.
Maybe if you tell what you wa
Rodrigo Gonzalez wrote:
I answer here so each one can help you.
Cannot understand what you meanindex is numbered? Are you talking
about "autoincrement" as called in mysql? use sequences please
Sorry, forgot that your email address was in the reply-to field.
I was seeking a solution on
I answer here so each one can help you.
Cannot understand what you meanindex is numbered? Are you talking
about "autoincrement" as called in mysql? use sequences please
Best regards
Rodrigo
Poul Møller Hansen wrote:
Rodrigo Gonzalez wrote:
Poul,
2 thingsfirst, why do you think i
And InnoDB is actually quite a bit worse than PostgreSQL (ignoring the
slight difference in row numbers)
InnoDB:
olp_live> select count(*) from team_players;
+--+
| count(*) |
+--+
| 465004 |
+--+
1 row in set (1.54 sec)
PostgreSQL:
olp_live=# select count(*) from t
Poul Møller Hansen <[EMAIL PROTECTED]> writes:
> My questions is, which statements can use to count the rows faster ?
> 32 secs compared to 10 ms !
Try starting a transaction in one window updating one of those records and see
how long it takes your count(*) to complete in the other window while
Poul,
2 thingsfirst, why do you think it will have an impact on inserts?
And the second oneuse InnoDb tables in MySQL, and you will have the
same than with PostgreSQL, it's because of MVCC
Best regards
Rodrigo
Poul Møller Hansen wrote:
I can see it has been discussed before, why CO
14 matches
Mail list logo
