Skip to main content
added 8 characters in body
Source Link
Evan Carroll
  • 64.7k
  • 49
  • 251
  • 496

why when i search on zip_ lets say '90210' it comes back with 0 rows when I know there is thousands of records with the zip code of '90210'?

Because you may have characters inside the zip code that you're not expecting, like spaces, non-breaking spaces, or some other fun unicode thing.

if i change the type to int would that make a difference?

If you're only storing US Zip Codes (and only the 5-digit model at that) you can store zip codes in an int.

ALTER TABLE foo ALTER zip
  SET DATA TYPE int
  USING (trim(zip)::int);

That's smaller/faster.

do i need an index on the zip_ column?

Yes, if it's in a where clause there is a good chance the database can make use of an index.

Better idea

Alternatively, you could geocode, resolve to WGS84 addresses and store the lat/long in in a database using PostGIS's geography(POINT). Then you can calculate distances and finding the nearest point on the index.

why when i search on zip_ lets say '90210' it comes back with 0 rows when I know there is thousands of records with the zip code of '90210'?

Because you may have characters inside the zip code that you're not expecting, like non-breaking spaces or some other fun unicode thing.

if i change the type to int would that make a difference?

If you're only storing US Zip Codes (and only the 5-digit model at that) you can store zip codes in an int.

ALTER TABLE foo ALTER zip
  SET DATA TYPE int
  USING (trim(zip)::int);

That's smaller/faster.

do i need an index on the zip_ column?

Yes, if it's in a where clause there is a good chance the database can make use of an index.

why when i search on zip_ lets say '90210' it comes back with 0 rows when I know there is thousands of records with the zip code of '90210'?

Because you may have characters inside the zip code that you're not expecting, like spaces, non-breaking spaces, or some other fun unicode thing.

if i change the type to int would that make a difference?

If you're only storing US Zip Codes (and only the 5-digit model at that) you can store zip codes in an int.

ALTER TABLE foo ALTER zip
  SET DATA TYPE int
  USING (trim(zip)::int);

That's smaller/faster.

do i need an index on the zip_ column?

Yes, if it's in a where clause there is a good chance the database can make use of an index.

Better idea

Alternatively, you could geocode, resolve to WGS84 addresses and store the lat/long in in a database using PostGIS's geography(POINT). Then you can calculate distances and finding the nearest point on the index.

Source Link
Evan Carroll
  • 64.7k
  • 49
  • 251
  • 496

why when i search on zip_ lets say '90210' it comes back with 0 rows when I know there is thousands of records with the zip code of '90210'?

Because you may have characters inside the zip code that you're not expecting, like non-breaking spaces or some other fun unicode thing.

if i change the type to int would that make a difference?

If you're only storing US Zip Codes (and only the 5-digit model at that) you can store zip codes in an int.

ALTER TABLE foo ALTER zip
  SET DATA TYPE int
  USING (trim(zip)::int);

That's smaller/faster.

do i need an index on the zip_ column?

Yes, if it's in a where clause there is a good chance the database can make use of an index.