Re: Re: 7.2 items

Lincoln Yeoh wrote:
> 
> 
> 2) Some form of synchronous "wait" which blocks till an event happens (no
> need to poll at all).
> e.g.
> WAIT('sendmessagetomain');
> 
> NOTIFY('sendmessagetomain') gets things going. If not possible to reuse
> NOTIFY, then something else will do.
> 
> This allows many programs on various hosts to wait for an event before
> doing things.
> 
> The present async-io stuff has traces of polling left, can't be done in a
> transaction and can't be used with Perl DBI (and maybe other standard DB
> interfaces).

What do you do if you are waiting on come other message - drop it,
reorder 
messages, something else ?

> 3) And the notorious VACUUM and VACUUM analyze :).
> How about:
> VACUUM <table> lazy; (don't lock table)
> VACUUM <table> [hardworking];
> analyze <table>  [randomsample];
> analyze <table> full;
> 
> Probably syntax should be different so as not to increase the number of
> reserved words.

Maybe some SET variable ?

SET VACUUM TO "LAZY";
SET VACUUM TO "ANALYZE EVERYTHING YOU CAN IN 15 MINUTES";

> 4) Not really important to me but can serial be a proper type or something
> so that drop table will drop the linked sequence as well?
> Maybe:
>  serial = old serial for compatibility
>  serial4 = new serial
>  serial8 = new serial using bigint
> (OK so 2 billion is big, but...)
> 
> 5) How will the various rollovers be handled e.g. OID, TID etc? What
> happens if OIDs are not unique? As things get faster and bigger a nonunique
> OID in a table might just happen.

OID's should _not_ be allowed to be non-unique, it is like spending
resources 
on "what if 2+2=5" scenarios.

I think that all system *IDs should be allowed to be 64 bits - XID reuse
is 
a kludge that can serve the immediate problem of DB freezing when
running out 
of transaction IDs - but I don't like it as a long-term solution.

-------------------
Hannu