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 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 such
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:
2009/1/8 Richard Heyes rich...@php.net:
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
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
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
2009/1/7 Ross McKay ro...@zeta.org.au:
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
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 both,
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.
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
On 1/7/09, Jim Lyons jlyons4...@gmail.com 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
On Wed, Jan 7, 2009 at 9:17 AM, David Giragosian dgiragos...@gmail.com wrote:
On 1/7/09, Jim Lyons jlyons4...@gmail.com 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
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 luxury, but those
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
when 1Gb
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 you have
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. If
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
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 storage
2009/1/7 Ashley Sheridan a...@ashleysheridan.co.uk:
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
On Thu, 2009-01-08 at 01:07 +0200, Dotan Cohen wrote:
2009/1/7 Ashley Sheridan a...@ashleysheridan.co.uk:
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
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 of
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.
Not on
...
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
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
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).
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).
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:
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
2009/1/5 Frank Stanovcak blindspot...@comcast.net:
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
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
On Tue, Jan 6, 2009 at 10:43 AM, Dotan Cohen dotanco...@gmail.com wrote:
2009/1/5 Frank Stanovcak blindspot...@comcast.net:
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
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 seems it's internal
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:
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
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.
I'd be
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
2009/1/5 Frank Stanovcak blindspot...@comcast.net:
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
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
On Mon, Jan 5, 2009 at 14:05, Frank Stanovcak blindspot...@comcast.net 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
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, 2009-01-05 at 19:15 +, Stuart wrote:
2009/1/5 Frank Stanovcak blindspot...@comcast.net:
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
On Mon, Jan 5, 2009 at 14:54, Robert Cummings rob...@interjinn.com 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 P. Brown
daniel.br...@parasane.net || danbr...@php.net
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, but
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 MySQL, varchar can
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
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
manual page
46 matches
Mail list logo
