From PostgreSQL wiki
Information about Kevin Grittner and his activities.
I've been making my living working with computers since 1972. In 1980 I founded a consulting company I ran until 2005; during that time I worked with a wide variety of applications, organizations, and technical environments. I'm now with EnterpriseDB as a database architect. I'm a committer for the free, open source version of PostgreSQL, and an active member of the community.
I co-authored the patch for PostgreSQL implementation of Serializable Snapshot Isolation (SSI) which went into PostgreSQL version 9.1. This was a joint project with Dan R.K. Ports of MIT, with helpful input and support from many in the PostgreSQL community. Our paper on that effort can be found here:
For the PostgreSQL docs on the feature, see:
For a number of examples see:
I also developed the initial implementation of materialized views for PostgreSQL version 9.3. Documentation is here:
I have been working on extending support for materialized views in future versions.
Current Work In Process
Declarative materialized views
REFRESH MATERIALIZED VIEW CONCURRENTLY support has been committed for inclusion in the next release.
Work is in progress to support incremental maintenance of materialized views.
Possible Future Work
Some issues I have run into which I might want to come back to are listed here, as sort of a personal "to do" list, time permitting.
Rewrite tsearch parser to use regular expressions
In reviewing a patch to fix some performance problems in the current parser, I became interested in the possibility of rewriting the current state machine implementation with a regular expression implementation.
Deleted WAL files held open by backends in Linux
I wasted some time tracking down an oddity which is more of an annoyance in system administration than a real problem, but might look at cleaning it up to save others the bother of investigating the issue.
Temporal data improvements
Temporal data handling is weak in SQL in general, and the PostgreSQL implementation seems skewed toward scientific or engineering applications, leaving it weaker than some databases on business applications. (One example would be clean handling of monthy payment schedules.) Enhancements to this area might be interesting.
LSB script compliance
I came up with a pretty LSB compliant script for Linux; however, the community feels that most of the logic handled in the shell in this script should be moved into pg_ctl. There's a pretty long and winding thread on the topic. The last version of the script might be useful to identify what issues need to be covered in the current pg_ctl code.
There have been a few posts to the lists about specific use cases where TOAST defaults are far from optimal. Allowing some tuning here might be helpful.
Literal and NULL handling anomalies
There are a few corner cases where differences between standard and PostgreSQL behaviors with string literals or NULLs astonish those new to PostgreSQL. These aren't easily solved, but might be worth the effort.
Language is not always as readable as it could be, and some files still largely read like proposals for features which are now implemented.