Re: Call for 7.5 feature completion

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 <rm_pg(at)cheapcomplexdevices(dot)com> 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
>