lldate BETWEEN '2007-07-01 00:00:00' AND '2007-07-30 23:59:59'
)
GROUP BY day, disposition;
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 25, 2007 10:03 PM
To: Edoardo Serra
Cc: mysql@lists.mysql.com
Subject: Re: MyISAM v
ssage-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 25, 2007 10:03 PM
To: Edoardo Serra
Cc: mysql@lists.mysql.com
Subject: Re: MyISAM vs InnoDB - Index choice and Huge performance difference
just want to take a note on 4Gbytes
What kernel u use?
4Gbytes or bigger m
Tnx for your interest
# uname -a
Linux corona 2.6.18-5-amd64 #1 SMP Thu May 31 23:51:05 UTC 2007 x86_64
GNU/Linux
64 bit shouldn't have problems in using 4gb of ram .. right ?
[EMAIL PROTECTED] ha scritto:
just want to take a note on 4Gbytes
What kernel u use?
4Gbytes or bigger means nothi
#x27; AND '2007-07-30 23:59:59'
)
GROUP BY day, disposition;
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Sunday, November 25, 2007 10:03 PM
> To: Edoardo Serra
> Cc: mysql@lists.mysql.com
> Subject: Re: MyISAM vs Inno
U might want to try seting you index to calldate, disposition
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 25, 2007 10:03 PM
To: Edoardo Serra
Cc: mysql@lists.mysql.com
Subject: Re: MyISAM vs InnoDB - Index choice and Huge performance
just want to take a note on 4Gbytes
What kernel u use?
4Gbytes or bigger means nothing on your MySQL, because if your kernel
is not compiled using correct patch or simply use CentOS/RHEL, then
your MySQl will limited to use up to 2Gbytes only, so 4Gbytes -->
2Gbytes is useless
On 11/25/07, E
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7 Nov 2006, at 12:35, Jochem van Dieten wrote:
On 11/6/06, Leandro Guimarães Faria Corcete DUTRA wrote:
Em Thu, 02 Nov 2006 10:22:18 -0800, Jochem van Dieten escreveu:
PostgreSQL supports 2 phase commit. IIRC except for transaction
interleavi
On 11/6/06, Leandro Guimarães Faria Corcete DUTRA wrote:
Em Thu, 02 Nov 2006 10:22:18 -0800, Jochem van Dieten escreveu:
PostgreSQL supports 2 phase commit. IIRC except for transaction
interleaving, join and suspend/resume it supports XA. I think that puts it
about on par with Ingres and Firebi
> > On two-phase commits? I guess it's the IB 6 docs where you have to read
> > that, or get a copy of Helen Borries Firebird book. Get a copy of the
> > IBPhoenix CD that includes docs.
> >
> > The Firebird project itself has no full documentation yet - it's being
> > worked on.
>
> Hm, do you me
Em Thu, 02 Nov 2006 10:22:18 -0800, Jochem van Dieten escreveu:
> PostgreSQL supports 2 phase commit. IIRC except for transaction
> interleaving, join and suspend/resume it supports XA. I think that puts it
> about on par with Ingres and Firebird.
I would have to analyze better, but I thi
Em Fri, 03 Nov 2006 09:18:21 +0100, Martijn Tonies escreveu:
> On two-phase commits? I guess it's the IB 6 docs where you have to read
> that, or get a copy of Helen Borries Firebird book. Get a copy of the
> IBPhoenix CD that includes docs.
>
> The Firebird project itself has no full documentati
> > InterBase had two-phase commits ages ago, Firebird inherited it.
> >
> > If there's anything specific you want to know, ask
>
> I *am* asking — where is the specific piece of documentation?
On two-phase commits? I guess it's the IB 6 docs where you have
to read that, or get a copy of Helen Bo
Em Thu, 02 Nov 2006 17:40:44 +0100, Martijn Tonies escreveu:
> InterBase had two-phase commits ages ago, Firebird inherited it.
>
> If there's anything specific you want to know, ask
I *am* asking — where is the specific piece of documentation?
Because if you don’t read MySQL’s
Em Thu, 02 Nov 2006 17:30:14 +0100, Martijn Tonies escreveu:
> Falcon has a transactional storage engine, including Foreign
> Keys (Jim wouldn't do a database without em)
Obviouſly.
> MGA
Ma ze?
--
Leandro Guimarães Faria Corcete DUTRA +55 (11) 9406 7191 (cel)
Administrado
On 11/2/06, Leandro Guimarães Faria Corcete DUTRA wrote:
Em Wed, 01 Nov 2006 09:34:05 -0600, mos escreveu:
> Is there a better open source database out there for that amount of data?
Several. MySQL's own MaxDB, PostgreSQL, Firebird if you are into
Borland stuff, Ingres if you need XA
> >> Several. MySQL’s own MaxDB, PostgreSQL, Firebird if you are into
> >> Borland stuff, Ingres if you need XA distributed transactions.
> >
> > Firebird isn't Borland
>
> Granted. But it is (even more) attractive if you are already a Borland
> shop.
>
>
> >> I usually recommend PostgreSQL
Em Thu, 02 Nov 2006 15:32:06 +0100, Martijn Tonies escreveu:
>> Several. MySQL’s own MaxDB, PostgreSQL, Firebird if you are into
>> Borland stuff, Ingres if you need XA distributed transactions.
>
> Firebird isn't Borland
Granted. But it is (even more) attractive if you are alrea
>> > > Is there a better open source database out there for that amount of
>>data?
>> >
>> > Several. MySQLâ?Ts own MaxDB, PostgreSQL, Firebird if you are
into
>> > Borland stuff, Ingres if you need XA distributed transactions.
>>
>>Firebird isn't Borland :-)
>>
>> > I usually recommend Postg
At 08:32 AM 11/2/2006, you wrote:
> >> Always use a DBMS, and MySQL is no (proper) DBMS without a
> >> transactional backend. There are InnoDB, which is not completely free
(needs
> >> a proprietary backup tool); BDB, which is deprecated until further
notices;
> >> and SolidDB, which is
> >> Always use a DBMS, and MySQL is no (proper) DBMS without a
> >> transactional backend. There are InnoDB, which is not completely free
(needs
> >> a proprietary backup tool); BDB, which is deprecated until further
notices;
> >> and SolidDB, which is still β.
> >
> > Ok, so your soluti
Em Wed, 01 Nov 2006 09:34:05 -0600, mos escreveu:
> At 05:56 AM 11/1/2006, Leandro Guimarães Faria Corcete DUTRA wrote:
>>
>> Always use a DBMS, and MySQL is no (proper) DBMS without a
>> transactional backend. There are InnoDB, which is not completely free (needs
>> a proprietary backup
On 11/1/06, mos wrote:
At 02:27 PM 11/1/2006, Jochem van Dieten wrote:
What is the big deal of a TB? Now, if you get past 20 TB you might
want to team up with one of the commercial PostgreSQL supporters
(Fujitsu, EnterpriseDB, Greenplum etc.), but Sun even sells appliances
for 100 TB PostgreSQL
At 02:27 PM 11/1/2006, Jochem van Dieten wrote:
On 11/1/06, mos wrote:
Sure, I've thought of those too. But has anyone gotten Firebird to
store 700-800gb tables? Can you split Firebird's .gdb file across drives?
The main problem with tables of that size is maintaining the index. My
upp
On 11/1/06, mos wrote:
Sure, I've thought of those too. But has anyone gotten Firebird to
store 700-800gb tables? Can you split Firebird's .gdb file across drives?
The main problem with tables of that size is maintaining the index. My
upper limit for MySQL is 100 million rows. After tha
At 09:35 AM 11/1/2006, Martijn Tonies wrote:
>> > MyISAM vs InnoDB ? What is the best to use
>>
>> Always use a DBMS, and MySQL is no (proper) DBMS without a
>> transactional
>>backend. There are InnoDB, which is not completely free (needs a
proprietary
>>backup tool); BDB, which is depr
Francis wrote:
Question about MyISAM vs InnoDB ? What is the best to use, I have
a large table contain around 10 millons of records. What is the best
for me ? Use MyISAM or InnoDB ?
Depends VERY much on your application. If any concurrency and/or
durability is required then I would
Francis wrote:
Question about MyISAM vs InnoDB ? What is the best to use, I have
a large table contain around 10 millons of records. What is the best
for me ? Use MyISAM or InnoDB ?
Depends VERY much on your application. If any concurrency and/or
durability is required then I would
>> > MyISAM vs InnoDB ? What is the best to use
>>
>> Always use a DBMS, and MySQL is no (proper) DBMS without a
>> transactional
>>backend. There are InnoDB, which is not completely free (needs a
proprietary
>>backup tool); BDB, which is deprecated until further notices; and SolidDB,
>>wh
At 05:56 AM 11/1/2006, Leandro Guimarães Faria Corcete DUTRA wrote:
Em Tue, 31 Oct 2006 15:24:44 -0500, Francis escreveu:
> MyISAM vs InnoDB ? What is the best to use
Always use a DBMS, and MySQL is no (proper) DBMS without a
transactional
backend. There are InnoDB, which is not com
On Nov 1, 2006, at 12:56 PM, Leandro Guimarães Faria Corcete DUTRA
wrote:
Em Tue, 31 Oct 2006 15:24:44 -0500, Francis escreveu:
MyISAM vs InnoDB ? What is the best to use
Always use a DBMS, and MySQL is no (proper) DBMS without a
transactional
backend. There are InnoDB, which is not co
Miles Thompson <[EMAIL PROTECTED]> wrote:
> At 07:56 AM 11/1/2006, Leandro Guimarães Faria Corcete DUTRA wrote:
> > .. further notices; and SolidDB, which
> >is still β.
>
> Help this poor English-speaker - what's the symbol you use to describe
> SolidDB?
I assume it is a "beta" character, sin
At 07:56 AM 11/1/2006, Leandro Guimarães Faria Corcete DUTRA wrote:
.. further notices; and SolidDB, which
is still β.
Choose your evil.
--
Leandro Guimarães Faria Corcete DUTRA +55 (11) 9406 7191 (cel)
Administrador de (Bases de) Dados +55 (11) 2122 0302 (com)
http://b
Em Tue, 31 Oct 2006 15:24:44 -0500, Francis escreveu:
> MyISAM vs InnoDB ? What is the best to use
Always use a DBMS, and MySQL is no (proper) DBMS without a transactional
backend. There are InnoDB, which is not completely free (needs a proprietary
backup tool); BDB, which is deprecated
Hello,
Although the number of records is a consideration to weigh in your decision,
there are many other (perhaps more important) factors to consider.
For example, do you need foreign keys? transactions? row-level locks?...then
InnoDB is your choice.
Perhaps with more details concerning the char
Hello.
>innodb_log_file_size=10M
>innodb_log_buffer_size=1M
These variables have too small values, increase them. Follow
other recomendations from:
http://dev.mysql.com/doc/refman/5.0/en/innodb-configuration.html
Andrew stolarz <[EMAIL PROTECTED]> wrote:
>
>hello, here are my cu
Is your database connection auto-commit? MyISAM commits everything at
once, where InnoDB you can commit whenever you want. You might want to
commit at the end of your batch.
Also, look at your indexes - indexes make selects fast, but slow down
inserts and deletes, and can slow down updates i
hello, here are my current setttings:
# MySQL Server Instance Configuration File
# --
# Generated by the MySQL Server Instance Configuration Wizard
#
#
# Installation Instructions
#
Hello.
Without seeing at least your configuration it is difficult to say
what's going on. Please, provide your config file.
Andrew stolarz <[EMAIL PROTECTED]> wrote:
>When I do a bulk import into a MyIsam engine database, I can reach about 2-3
>thousand records imported per second.
>
>
Eamon Daly wrote:
We have a table containing just one column that we use for
unique IDs:
CREATE TABLE `id_sequence` (
`id` int(10) unsigned NOT NULL auto_increment,
PRIMARY KEY (`id`)
) TYPE=MyISAM
Watching 'SHOW FULL PROCESSLIST' and reading the slow query
log shows the occasional backlog o
Hello.
If you have lots of concurrent updates and selects on the
same table, InnoDB usually has better performance. Use the
benchmarks to determine what configuration is preferred.
Super-smack for example allows you to write very flexible tests.
Be aware of different behavior of AUTO
<[EMAIL PROTECTED]>
> To: "Eamon Daly" <[EMAIL PROTECTED]>
> Cc:
> Sent: Wednesday, August 24, 2005 12:05 PM
> Subject: Re: MyISAM vs. InnoDB for an AUTO_INCREMENT counter table
>
>
> > "Eamon Daly" <[EMAIL PROTECTED]> wrote on 08/24/
Sent: Wednesday, August 24, 2005 12:05 PM
Subject: Re: MyISAM vs. InnoDB for an AUTO_INCREMENT counter table
"Eamon Daly" <[EMAIL PROTECTED]> wrote on 08/24/2005 12:40:55 PM:
We have a table containing just one column that we use for
unique IDs:
CREATE TABLE `id_sequence` (
`i
"Eamon Daly" <[EMAIL PROTECTED]> wrote on 08/24/2005 12:40:55 PM:
> We have a table containing just one column that we use for
> unique IDs:
>
> CREATE TABLE `id_sequence` (
> `id` int(10) unsigned NOT NULL auto_increment,
> PRIMARY KEY (`id`)
> ) TYPE=MyISAM
>
> Watching 'SHOW FULL PROCES
"Praveen KS" <[EMAIL PROTECTED]> writes:
> In a table of 20,000 records I am frequented with this error:
>
> Error 1034:
> Incorrect key file for table: ''; try to repair it
>
> Frequency of this error: Three or four times a week.
> I am logging the data it was trying to insert or update. Af
Hello.
>mysql Ver 14.3 Distrib 4.1.1-alpha, for pc-linux (i686)
You have an old MySQL version which contains lots of bugs (it's
an alpha!). I strongly recommend you to upgrade to the latest release
(4.1.12 now) and use official binaries.
>Hi,
>
>
>In a table of 20,000 records I a
Thanks Mike. I think testing ultimately determines how
efficient heterogeneous engine joins are. I just
wanted to know if someone had issues with them in a
heavy-load environment.
--- mos <[EMAIL PROTECTED]> wrote:
> At 04:00 PM 12/21/2004, Homam S.A. wrote:
> >Thanks Mike for the information.
At 04:00 PM 12/21/2004, Homam S.A. wrote:
Thanks Mike for the information. Yes, Emmett mentioned
the same thing in a private message, and it seems that
MyISAM is exactly what I'm looking for: a
heavily-indexed large table that will be also indexed
for full-text search and built off-line -- no updat
Homam S.A. wrote:
I'm new to MySQL and I was wondering which storage
engine is the best choice for heavily-indexed,
read-mostly data.
From skimming over the documentation, it seems that
MyISAM is a better choice since it doesn't have the
transactional overhead. Yet I'm worried that it's
becoming de
Thanks Mike for the information. Yes, Emmett mentioned
the same thing in a private message, and it seems that
MyISAM is exactly what I'm looking for: a
heavily-indexed large table that will be also indexed
for full-text search and built off-line -- no updates
whatsoever.
However, I will be joining
At 06:37 PM 12/20/2004, you wrote:
I'm new to MySQL and I was wondering which storage
engine is the best choice for heavily-indexed,
read-mostly data.
From skimming over the documentation, it seems that
MyISAM is a better choice since it doesn't have the
transactional overhead. Yet I'm worried that
On Thu, 13 May 2004 10:34:37 -0700 (PDT)
David Blomstrom <[EMAIL PROTECTED]> wrote:
> I thought that only InnoDB tables could be joined -
> and only if they had foreign keys. But it sounds like
> any kind of table can be joined, and it doesn't need a
> foreign key.
Exactly, you can do a join with
> I thought that only InnoDB tables could be joined -
> and only if they had foreign keys. But it sounds like
> any kind of table can be joined, and it doesn't need a
> foreign key.
The ability to join a bunch of tables in a query is different from foreign
keys. A foreign key is a relationhip be
Hi Alan,
> Thanks for that Chris, interesting thoughts.
>
> For clarification, there is *NO* UPDATEs running on this table. Not a
> single one! :) Many more SELECTs than INSERTs
If you value your data, and these INSERTs are part of
a multi-insert batch of related data, go with the table-type
th
Thanks for that Chris, interesting thoughts.
For clarification, there is *NO* UPDATEs running on this table. Not a
single one! :) Many more SELECTs than INSERTs
Chris Nolan wrote:
Alan Williamson wrote:
A quick question for the hardcore MySQL experts out there.
I have a simple table;
---
Alan Williamson wrote:
A quick question for the hardcore MySQL experts out there.
I have a simple table;
---
ID varchar (PK)
DATA longblob
---
This table is a simple persistence cache for one of our servers. It
regularly INSERTs and SELECTs into this table data o
55 matches
Mail list logo
