Re: 10+hrs vs 15min because of just one index

From: PFC <lists(at)peufeu(dot)com>
To: "Aaron Turner" <synfinatic(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, pgsql-performance(at)postgresql(dot)org
Subject: Re: 10+hrs vs 15min because of just one index
Date: 2006-02-13 08:55:20
Message-ID: op.s4wlqiikcigqcu@apollo13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


>> Are the key values really all 48 chars long? If not, you made a
>> bad datatype choice: varchar(n) (or even text) would be a lot
>> smarter. char(n) wastes space on blank-padding.
>
> Yep, everything exactly 48. Looks like I'll be storing it as a bytea
> in the near future though.

It's a good idea not to bloat a column by base64 encoding it if you want
to index it. BYTEA should be your friend.
If your values are not random, you might want to exploit the correlation.
But if they are already quite uncorrelated, and you don't need the index
for < >, just for =, you can create an index on the md5 of your column and
use it to search. It will use a lot less data but the data will be more
random. With a functional index, you don't need to modify your application
too much.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Markus Schaber 2006-02-13 11:49:15 Re: help required in design of database
Previous Message Michael Fuhr 2006-02-13 05:46:01 Re: SQL Function Performance