Are there theoretical performance "elbows" in tables with many records?

We are attempting to construct a policy which will restrict the number of
rows we keep online in a table that looks like this:

create table stuff (
a integer not null references other_a on delete cascade,
b integer not null references other_b on delete cascade,
c integer check (c >= 0),
primary key (a,b,c)
);
create index ix_stuff_1 on stuff (b);

We do a lot of queries against this table using column b.

Questions:

1) Would the primary key be more useful if defined as (b,a,c)? Would it
remove the need for an index on b itself?

2) Is there a performance "elbow" in query times vs. number of rows in
the table? (E.g., performance drops off dramatically at some number of
records.)

--
Jeff Boes vox 616.226.9550
Database Engineer fax 616.349.9076
Nexcerpt, Inc. jboes(at)nexcerpt(dot)com