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