At 01:20 PM 10-05-2001 -0400, Bruce Momjian wrote:
>Here is a small list of big TODO items. I was wondering which ones
>people were thinking about for 7.2?
>
>---------------------------------------------------------------------------
Well since you asked, here's my wish list for Postgresql 7.2.
1) Full text index to be used by LIKE queries.
e.g.
create index myfti_idx on mytable ( mysoundex(story,'british english')
fti_ops);
Usage:
select * from mytable where mysoundex(story,'british english') like
'%tomato%';
select * from mytable where mysoundex(story,'us english') like '%either%';
select * from mytable where mysynonym(story) like '%excellent%';
First select indexed. Other selects not indexed.
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).
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.
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 compatibilityserial4 = new serialserial8 = 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.
Cheerio,
Link.
