Обсуждение: Which index methodology is better?-

I have a question.

Consider this scenario.

Table customer (
customer_id int8,
customer_l_name varchar(35),
customer_f_name varchar(30),
customer_addr_1 varchar(100),\
customer_addr_2 varchar(100),
customer_city varchar(50),
customer_state char(2),
customer_zip varchar(9)
);

On this table, a customer can search by customer_id, customer_l_name,
and customer_f_name.

Is it better to create 3 indexes, or one index on the three columns?

I did some initial testing with index customer_test_idx(customer_id,
customer_l_name, customer_f_name) and postgres would use the index for
select * from customer where customer_f_name = 'zxy' - so the single
index will cover the three.

My question is, is this better?  Does it end up using less memory
and/or disk or more?  I am trying to find ways to keep more of my
customers databases in memory, and I am thinking that loading one
index is probably a little better than loading three.

Thanks for any advice,

Chris

PG 8.1
RH 4.0

"Chris Hoover" <revoohc@gmail.com> writes:
> Is it better to create 3 indexes, or one index on the three columns?

This is covered in considerable detail in the fine manual:

http://www.postgresql.org/docs/8.2/static/indexes.html

See particularly sections 11.3 and 11.4

            regards, tom lane

Chris Hoover wrote:
> On this table, a customer can search by customer_id, customer_l_name,
> and customer_f_name.
>
> Is it better to create 3 indexes, or one index on the three columns?
>
> I did some initial testing with index customer_test_idx(customer_id,
> customer_l_name, customer_f_name) and postgres would use the index for
> select * from customer where customer_f_name = 'zxy' - so the single
> index will cover the three.

Postgres can use the index in that case, but it's going to have to scan
the whole index, which is a lot slower than looking up just the needed
rows. If you do an EXPLAIN ANALYZE on that query, and compare it against
"select * from customer where customer_id = 123", you'll see that it's a
lot more expensive.

I'd recommend having separate indexes. Having just one index probably
does take less space, but the fact that you don't have to always scan
all of it probably outweighs that.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

If I do:

  begin;
  update some_table set foo = newvalue where a_bunch_of_rows_are_changed;
  analyze some_table;
  rollback;

does it roll back the statistics?  (I think the answer is yes, but I need to be sure.)

Thanks,
Craig

Craig James <craig_james@emolecules.com> writes:
> If I do:
>   begin;
>   update some_table set foo = newvalue where a_bunch_of_rows_are_changed;
>   analyze some_table;
>   rollback;

> does it roll back the statistics?  (I think the answer is yes, but I need to be sure.)

Yes --- ANALYZE doesn't do anything magic, just a plain UPDATE of those
rows.  (You could have easily tested this for yourself...)

            regards, tom lane