What's better here - a single column or multicolumn primary key?
Much of this is a matter of taste and style. And more importantly: specific requirements and consistent conventions. However, there are good reasons for this generic advice:

CREATE TABLE item (
    item_id serial PRIMARY KEY,
    grp_id  integer NOT NULL REFERENCES grp(grp_id)
);



If you have an item_id, better make it unique and ideally a surrogate primary key without any specific meaning for the number itself. That's cheap and versatile. Per-group (not per-row) serials are typically expensive, pointless effort. If you desire a gap-less numbering per group, add some kind of rank column or use row_number() in a view. And don't rely on a gap-less numbering if you can avoid it. Sooner or later you'll have to delete or move around items.
It is convenient for maintenance to have a single column primary key that follows a naming convention (unless you have an obvious natural pk).
Don't use group as identifier. It is a reserved word. Even if these are just symbolic names.
If you have queries by grp_id, add another index:

CREATE INDEX item_foo_idx ON item (grp_id, item_id);


You might want to make it a UNIQUE INDEX for documentation, but that's redundant since item_id is unique already. With two integer columns, a multicolumn index is just as big as an index on just grp_id and there seem to be use cases where you need these two columns, so there is the chance for a covering index. This should be the optimum. More rationale here:
Is a composite index also good for queries on the first field?