Skip site navigation (1) Skip section navigation (2)

Re: 7.4 Wishlist

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 7.4 Wishlist
Date: 2002-11-29 21:54:20
Message-ID: 1038606859.1940.64.camel@rh72.home.ee (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-generalpgsql-hackers
Christopher Kings-Lynne kirjutas R, 29.11.2002 kell 23:51:
> Hi guys,
> 
> Just out of interest, if someone was going to pay you to hack on Postgres
> for 6 months, what would you like to code for 7.4?
> 
> My ones are:
> 
> * Compliant ADD COLUMN
> * Integrated full text indexes
> * pg_dump dependency ordering
> 
> What would you guys do?  Even if it isn't feasible right now...

As I don't have a permanent job starting next year (my main employer
went bust), I'm planning to do more on postgreSQL anyway (at least until
I run out of money ;)

I have done some (or sometimes a lot of) brain-twitching on items in the
following list, but very little actual useful coding on most.

My personal todo list is:

"Application server support"
----------------------------
* better XML integration 
  
  - XML(*) aggregate function returning XML representation of subquery 

  - XML input/output to/from tables

  - XML searchable/indexable in fields)

* Overhaul of OO features (moving closer to SQL99)

  - type/table inheritance, 

    table inheritance would be done using SQL99's UNDER and would be
    single inheritance, stored in single logical table, possibly
    subdivided in physical tables reusing our current huge table 1GB
    split mechanisms

    type inheritance would be done using SQL99's LIKE and would be
    multiple inheritance and would reuse as much as possible the
    current code for ADD/DROP/RENAME column

    - check constraints would apply to both type and table inheritance

    - pk/fk constraints would apply only to table inheritance

  - types as base of tables,

  - study feasibility of reference types,

  - dynamic invocation of table function on queries over hierarchies


* WITH (as part of query/view)

* WITH RECURSIVE for recursive queries

* better NOTIFY (with optional argument, using shared memory
  instead of tables)


General stuff
-------------

* making array types btree-indexable in a general way

* study feasibility of using SQL99's ARRAY syntax for arrays

Data warehousing
----------------
* bitmap indexes,

  - using bitmap "indexes" internally for star joins

  - real bitmap indexes

  - clustered multiple bitmap indexes especially
    clustering on group of bitmap indexes

* clustering in general - specifying pages to be filled only to a
  certain percentage in clustered tables so that updated tuples can
  be placed near original ones if needed and parallel vacuum can
  then reclaim the space and keep table clustered with less shuffling.

* OLAP features
   - WINDOW clause, PARTITION BY
   - GROUPING SETS, ROLLUP, CUBE, () 


WAL-based master-slave replication
----------------------------------

* if someone is not doing it (which I hope is not true ;)


UNICODE / Localization
----------------------

* UTEXT, UCHAR, UVARCHAR types using IBM's ICU, stored in UTF-16 or SCSU

* fast LIKE, ILIKE, REGEX code for UTF-16, possibly lifted from python2

* field-level localization, again using ICU


FE/BE protocol
--------------

all can be worked on independently

* try to find a better wire protocol from existing ones (X-window
  system seems simple enough, perhaps DB2's DRDA) or fix the existing
  one for high performance (mainly make sure that as big chunks as
  possible have preceeding length), make it easy to send
  out-of-band/optional data (Notifications, info on actual query
  performance (so one can visualize it for user),  ...)

* standardize a fire-level binary protocol for field types (currently
  whatever is stored is sent)

* work on making python use this protocol and port some postgres
  datatypes (initially timestamp/date/time and varbit)to python 


Really Dark Arts
------------------

* making backend internals available to a scripting language (for me it
  means python ;) for making more parts (especially planner/optimizer)
  more easily hackable

* using the stuff from previous point ;)


And that's all ;)

----------------
Hannu Krosing



In response to

  • 7.4 Wishlist at 2002-11-29 18:51:26 from Christopher Kings-Lynne

Responses

pgsql-hackers by date

Next:From: Matthew T. O'ConnorDate: 2002-11-29 22:29:32
Subject: Re: 7.4 Wishlist
Previous:From: Tom LaneDate: 2002-11-29 21:22:40
Subject: Re: Thinking about IN/EXISTS optimization

pgsql-advocacy by date

Next:From: Matthew T. O'ConnorDate: 2002-11-29 22:29:32
Subject: Re: 7.4 Wishlist
Previous:From: Christopher Kings-LynneDate: 2002-11-29 18:51:26
Subject: 7.4 Wishlist

pgsql-general by date

Next:From: Matthew T. O'ConnorDate: 2002-11-29 22:29:32
Subject: Re: 7.4 Wishlist
Previous:From: Neil ConwayDate: 2002-11-29 20:22:06
Subject: Re: ALTER TABLE & COLUMN

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group