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