2009/1/8 Richard Heyes :
>> until you have to dump it, zip it, ssh it over to another box and then
>> import it back in
>
> That's what fag breaks are for... :-) Well, that and smoking.
>
http://xkcd.com/303/
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ
> So... when you're forgetful... have you ever had to bum a fag?
All the time... :-)
--
Richard Heyes
HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated January 4th)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.
On Thu, 2009-01-08 at 10:51 +, Richard Heyes wrote:
> > until you have to dump it, zip it, ssh it over to another box and then
> > import it back in
>
> That's what fag breaks are for... :-) Well, that and smoking.
So... when you're forgetful... have you ever had to bum a fag?
Words have suc
> until you have to dump it, zip it, ssh it over to another box and then
> import it back in
That's what fag breaks are for... :-) Well, that and smoking.
--
Richard Heyes
HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated January 4th)
--
PHP General Mailing List
On Thu, 2009-01-08 at 11:37 +1100, Ross McKay wrote:
> Richard Heyes wrote:
>
> >I've not come across many databases where 20-50 tables have 10 million
> >rows each. And with a table of that size, then I might be coerced into
> >thinking about the storage requirements a little more. Maybe.
>
> No
Richard Heyes wrote:
>I've not come across many databases where 20-50 tables have 10 million
>rows each. And with a table of that size, then I might be coerced into
>thinking about the storage requirements a little more. Maybe.
Not on MySQL, but I've worked on databases with hundreds of millions
On Thu, 2009-01-08 at 01:07 +0200, Dotan Cohen wrote:
> 2009/1/7 Ashley Sheridan :
> > Not just that, but aren't there greater overheads if the database is
> > physically larger in size? I assume that char might be a bit quicker to
> > work with than varchar, but I am pretty certain that using a fu
2009/1/7 Ashley Sheridan :
> Not just that, but aren't there greater overheads if the database is
> physically larger in size? I assume that char might be a bit quicker to
> work with than varchar, but I am pretty certain that using a fulltext
> index on a text field is ridiculously slow compared t
On Wed, 2009-01-07 at 21:18 +, Nathan Rixham wrote:
> Richard Heyes wrote:
> >> That's for a single table.
> >>
> >
> > I've not come across many databases where 20-50 tables have 10 million
> > rows each. And with a table of that size, then I might be coerced into
> > thinking about the s
Richard Heyes wrote:
That's for a single table.
I've not come across many databases where 20-50 tables have 10 million
rows each. And with a table of that size, then I might be coerced into
thinking about the storage requirements a little more. Maybe.
Now add another 20 to 50 tables d
> That's for a single table.
I've not come across many databases where 20-50 tables have 10 million
rows each. And with a table of that size, then I might be coerced into
thinking about the storage requirements a little more. Maybe.
> Now add another 20 to 50 tables depending on
> the database. I
On Wed, 2009-01-07 at 13:26 +, Richard Heyes wrote:
> >>So where's the advantage of VARCHAR ?
> >
> > Less space on disc = less data retrieved from disc = faster data
> > retrieval - sometimes. If you have small columns, a small number of
> > rows, or both, then char columns may be faster. If y
On Wed, 2009-01-07 at 10:49 +, Richard Heyes wrote:
> >> it' may seem like a small amount of space but when you have 8
> >> char(255) columns in a table with 10 million rows you'd noticed the
> >> difference considerably.
>
> It is a small amount of space. Perhaps it was necessary in the days
Richard Heyes wrote:
>>> it' may seem like a small amount of space but when you have 8
>>> char(255) columns in a table with 10 million rows you'd noticed the
>>> difference considerably.
>>>
>
> It is a small amount of space. Perhaps it was necessary in the days
> when 1Gb Hdds were a luxur
On Wed, Jan 7, 2009 at 9:17 AM, David Giragosian wrote:
> On 1/7/09, Jim Lyons wrote:
>>
>> There are other factors. If a table is completely fixed in size it makes
>> for a faster lookup time since the offset is easier to compute. This is
>> true, at least, for myisam tables. All books on tun
On 1/7/09, Jim Lyons wrote:
>
> There are other factors. If a table is completely fixed in size it makes
> for a faster lookup time since the offset is easier to compute. This is
> true, at least, for myisam tables. All books on tuning that I have read
> have said the CHAR makes for more effici
There are other factors. If a table is completely fixed in size it makes
for a faster lookup time since the offset is easier to compute. This is
true, at least, for myisam tables. All books on tuning that I have read
have said the CHAR makes for more efficient lookup and comparison that
VARCHAR.
Stuart wrote:
>Got anything to back that up?
>
>http://www.mysqlperformanceblog.com/2008/01/24/enum-fields-vs-varchar-vs-int-joined-table-what-is-faster/
Thanks, that'll do nicely. Even that strapped chicken test with tables
that are likely cached shows enum as the fasted, albeit only marginally.
>>So where's the advantage of VARCHAR ?
>
> Less space on disc = less data retrieved from disc = faster data
> retrieval - sometimes. If you have small columns, a small number of
> rows, or both, then char columns may be faster. If you have large
> columns of varying actual length, lots of rows, or
2009/1/7 Ross McKay :
> Oh, and for a column with a limited range of values, enum beats 'em all!
Got anything to back that up?
http://www.mysqlperformanceblog.com/2008/01/24/enum-fields-vs-varchar-vs-int-joined-table-what-is-faster/
-Stuart
--
http://stut.net/
--
PHP General Mailing List (ht
Richard Heyes wrote:
>So where's the advantage of VARCHAR ?
Less space on disc = less data retrieved from disc = faster data
retrieval - sometimes. If you have small columns, a small number of
rows, or both, then char columns may be faster. If you have large
columns of varying actual length, lots
>> it' may seem like a small amount of space but when you have 8
>> char(255) columns in a table with 10 million rows you'd noticed the
>> difference considerably.
It is a small amount of space. Perhaps it was necessary in the days
when 1Gb Hdds were a luxury, but those days are long gone. In the
On Wed, Jan 07, 2009 at 08:38:03AM +1100, Chris wrote:
> Nathan Rixham wrote:
>> chris smith wrote:
It may be worth mentioning that, IIRC, CHAR is faster due to the fixed
length. If you can make your table use a fixed length row size (ie no
variable length columns), it'll be faster.
Nathan Rixham wrote:
chris smith wrote:
It may be worth mentioning that, IIRC, CHAR is faster due to the fixed
length. If you can make your table use a fixed length row size (ie no
variable length columns), it'll be faster.
I'd be interested in seeing tests about this.. I doubt there's any
di
Frank Stanovcak wrote:
I know!
This ranks up there with redirecting people to www.ratemypoo.com when an
intrusion attempt is detected as part of the security measures.
ahh i redirect them to the endless sixapart atom stream seing as it's
normally spiders/bots - slows them down a bit :p
--
Nathan Rixham wrote:
> Richard Heyes wrote:
Also I could be missing
something, but I can't see the advantage in VARCHAR since space is not
really a concern these days.
>>> char is fixed length and padded. If you don't fill up the space, the
>>> db does it for you (even though it seem
On Tue, Jan 6, 2009 at 10:43 AM, Dotan Cohen wrote:
> 2009/1/5 Frank Stanovcak :
>> It's been a while since I've programed (VB was on version 4) I was wondering
>> if any one could tell me what the diff is between char, varchar, and text in
>> mysql.
>> I know this isn't a mysql news group, but si
Frank Stanovcak wrote:
So what I'm taking away from this is that I can index a text column, but
that is relatively new. Based on experience with technology I'm going to
guess it's not a very efficient index or search function yet. CHAR seems to
be well entrenched, and the favorite for any col
2009/1/5 Frank Stanovcak :
> It's been a while since I've programed (VB was on version 4) I was wondering
> if any one could tell me what the diff is between char, varchar, and text in
> mysql.
> I know this isn't a mysql news group, but since I am using php for the
> interaction it seemed like the
So what I'm taking away from this is that I can index a text column, but
that is relatively new. Based on experience with technology I'm going to
guess it's not a very efficient index or search function yet. CHAR seems to
be well entrenched, and the favorite for any column I may need to search
chris smith wrote:
It may be worth mentioning that, IIRC, CHAR is faster due to the fixed
length. If you can make your table use a fixed length row size (ie no
variable length columns), it'll be faster.
I'd be interested in seeing tests about this.. I doubt there's any difference.
quote: http
Richard Heyes wrote:
Also I could be missing
something, but I can't see the advantage in VARCHAR since space is not
really a concern these days.
char is fixed length and padded. If you don't fill up the space, the
db does it for you (even though it seems it's internal only).
http://dev.mysql.co
>> Also I could be missing
>> something, but I can't see the advantage in VARCHAR since space is not
>> really a concern these days.
>
> char is fixed length and padded. If you don't fill up the space, the
> db does it for you (even though it seems it's internal only).
>
> http://dev.mysql.com/doc/
> It may be worth mentioning that, IIRC, CHAR is faster due to the fixed
> length. If you can make your table use a fixed length row size (ie no
> variable length columns), it'll be faster.
I'd be interested in seeing tests about this.. I doubt there's any difference.
> Also I could be missing
>
> ...
It may be worth mentioning that, IIRC, CHAR is faster due to the fixed
length. If you can make your table use a fixed length row size (ie no
variable length columns), it'll be faster. Also I could be missing
something, but I can't see the advantage in VARCHAR since space is not
really a conc
On Tue, 2009-01-06 at 11:01 +1100, Ross McKay wrote:
> Micah Gersten wrote:
>
> >You're referencing the 5.1 manual. In the 5.0 manual it says that
> >VARCHAR was extended to 65535 in 5.0.3, so you're statement is not
> >entirely correct, nor was Stuart's. That's why I linked him to the 5.0
> >ma
Micah Gersten wrote:
>You're referencing the 5.1 manual. In the 5.0 manual it says that
>VARCHAR was extended to 65535 in 5.0.3, so you're statement is not
>entirely correct, nor was Stuart's. That's why I linked him to the 5.0
>manual page on data types.
Good point, thanks! I usually read from
Ross McKay wrote:
> First, start here:
>
> http://dev.mysql.com/doc/refman/5.1/en/string-types.html
>
> Stuart wrote:
>
>
>>> varchar: only the space required for the content of the field is
>>> allocated per row but these fields are limited to 255 chars (IIRC) in
>>> length.
>>>
>
> In M
First, start here:
http://dev.mysql.com/doc/refman/5.1/en/string-types.html
Stuart wrote:
>> varchar: only the space required for the content of the field is
>> allocated per row but these fields are limited to 255 chars (IIRC) in
>> length.
In MySQL, varchar can hold "up to" 65,535 characters,
On Mon, Jan 5, 2009 at 14:54, Robert Cummings wrote:
>
> It's generally worth mentioning that you can usually index char or
> varchar, but not text.
Actually, you can with MyISAM tables using FULLTEXT.
--
daniel.br...@parasane.net || danbr...@php.net
http://www.parasane.net/ || http://www.
On Mon, 2009-01-05 at 19:15 +, Stuart wrote:
> 2009/1/5 Frank Stanovcak :
> > It's been a while since I've programed (VB was on version 4) I was wondering
> > if any one could tell me what the diff is between char, varchar, and text in
> > mysql.
> > I know this isn't a mysql news group, but si
Frank Stanovcak wrote:
> It's been a while since I've programed (VB was on version 4) I was wondering
> if any one could tell me what the diff is between char, varchar, and text in
> mysql.
> I know this isn't a mysql news group, but since I am using php for the
> interaction it seemed like the
On Mon, Jan 5, 2009 at 14:05, Frank Stanovcak wrote:
> It's been a while since I've programed (VB was on version 4) I was wondering
> if any one could tell me what the diff is between char, varchar, and text in
> mysql.
> I know this isn't a mysql news group, but since I am using php for the
> int
Thank you. I have a stupid/nasty habit of realizing I can search after I
post a question. Problem was I was overwhelmed on google. I was hoping for
a simple this type is good for this use because, but bad for other things
because. type answer.
My mantra around this office is "I'm old not add
2009/1/5 Frank Stanovcak :
> It's been a while since I've programed (VB was on version 4) I was wondering
> if any one could tell me what the diff is between char, varchar, and text in
> mysql.
> I know this isn't a mysql news group, but since I am using php for the
> interaction it seemed like the
It's been a while since I've programed (VB was on version 4) I was wondering
if any one could tell me what the diff is between char, varchar, and text in
mysql.
I know this isn't a mysql news group, but since I am using php for the
interaction it seemed like the place to ask. Thanks in advance,
46 matches
Mail list logo
