Re: 7.2 items

From: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 7.2 items
Date: 2001-05-14 03:44:39
Message-ID: 3.0.5.32.20010514114439.01488390@192.228.128.13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 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.

Cheerio,
Link.

In response to

  • 7.2 items at 2001-05-10 17:20:59 from Bruce Momjian

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2001-05-14 05:03:22 Re: todo - I want the elog() thingy
Previous Message Steve O'Hagan 2001-05-14 03:17:11 Re: Internet is putting lot of competition fire & heat under Microsoft SQL Server