At 10:35 AM 2/18/2004 -0700, scott.marlowe wrote:
It works, I just like writing things in the most self documenting manner
possible, since one day somebody else may look at:
select * from test where id='456'
and go, "hey, that's just an int, no need for the quotes" and take them
out not knowing wh
On Wed, 18 Feb 2004, Lincoln Yeoh wrote:
> At 04:14 PM 2/17/2004 -0700, scott.marlowe wrote:
> >custom type (hex, foobar, etc...) from one to another. What this means
> >too you, the user, is that:
> >
> >create table test (id int8, info text);
> >
> >select * from test where id=456;
> >
> >will
Lincoln Yeoh wrote:
At 04:14 PM 2/17/2004 -0700, scott.marlowe wrote:
custom type (hex, foobar, etc...) from one to another. What this means
too you, the user, is that:
create table test (id int8, info text);
select * from test where id=456;
will result in a sequential scan. Why? Because the de
At 04:14 PM 2/17/2004 -0700, scott.marlowe wrote:
custom type (hex, foobar, etc...) from one to another. What this means
too you, the user, is that:
create table test (id int8, info text);
select * from test where id=456;
will result in a sequential scan. Why? Because the default integer type
i
Chris Fossenier wrote:
I currently have a client with a database that must hold 125 million records
and all tallied about 250 fields.
The database has been normalized and indexed appropriately.
If any of you have worked with MySQL, you will have discovered that indexing
is very limited. You ca
I had this same problem not long ago, and it caused me go with PostgreSQL over MySQL on a project. The problem you're describing does not exist in PostgreSQL. Creating a new index on a table does not require recreating the other indexes. MySQL also has the same problem if you add or drop columns
