Hi all, Our organizations are doing a lot of real time reporting involving queries with multiple tables, and large tables. I found that two features are very nice to have: - Table Partition - Materialized view
Thanks, J On 8/26/05, Ron Mayer <[EMAIL PROTECTED]> wrote: > Alvaro Herrera wrote: > > > Or, slightly different, what are people's most wanted features? > > Things I would have found useful in the past year or so include: > > Standards stuff: > > * Updateable views (easier to use Ruby/Rails's ActiveRecord on legacy data) > * The elementary OLAP stuff > > Contrib related stuff: > > * Contrib/xml2 working with XML Namespaces. > * Some sort of GIST index for querying XML data (XPath? SQL/XML?) > > * The array functions and indexes from contrib/intarray > and contrib/intagg made more general to work with other > data types. (I find these contrib modules quite useful) > > Annoyances: > > * more sane math with intervals. For example, try: > select '0.01 years'::interval, '0.01 months'::interval; > > Ease of use: > > * Nice defaults for autovacuum and checkpoints and bgwriter > that automatically avoid big I/O spikes by magically > distributing I/O in a nice way. > > Easier COPY for client library authors: > > * A way to efficiently insert many values like COPY from STDIN > from client libraries that don't support COPY from STDIN. > Perhaps it could happen through the apparently standards > compliant > "INSERT INTO table VALUES (1,2),(3,4),(5,6)" [feature id F641] > or perhaps through a new > COPY tablename FROM STRING 'a big string instead of stdin' > feature that would be easier for clients to support? > > It seems in most new client libraries COPY FROM STDIN > stays broken for quite a long time. Would a > alternative COPY FROM A_BIG_STRING be easier for them > to support and therefore available more often? > > Meta-stuff > > * A failover plus load-balancing (pgpool+slony?) > installer for dummies that handles simple cases. > > * A single place to find all the useful non-core stuff > like projects on pgfoundry, gborg, contrib, and > various other places around the net (PL/R PL/Ruby Postgis). > Perhaps if the postgresql website had a small wiki > somewhere where anyone could add links with a short > description to any such projects it'd be easier to > know what's out there... > > * Nice APIs and documentation [probably already exists] > to continue encouraging projects like PostGIS and PL/R > that IMHO are the biggest advantage of postgresql over > the commercial vendors' offerings. > > Oh, and seeing everyone else's response, I suppose I should > add MERGE though I haven't actually noticed a need yet. :-) > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
