Experimental Feature development in PostgreSQL

Neil Conway wrote:
<snip>

Hi everyone,

This is getting me to think :

We don't have a really established process for PostgreSQL development
which allows for "experimental features". aka the Linux kernel
"EXPERIMENTAL", and so forth.

aka ./configure --experimental-querycache
--experimental-pertablecostings --expermental-something?

This way, people can still use PostgreSQL as per normal, but it also
allows for development of code which might or might not actually see the
light of day, depending on if it turns out to really be useful.

By default, things should only become "experimental features" after the
correct consideration, not by default. There are situations where it
would be beneficial (perhaps in Neil's example here). If Neil were to
split off a project and do it on Sourceforge, then only some people
would check it out when kind of ready, etc, etc and it wouldn't really
be as available to a wider audience. But if's it part of the present
source tree, I think the experimental features would see a wider
audience and we'd get a better indication of what's good/bad/etc.

Don't know how to support those features, but pretty much developers and
hard-core-users should be the only ones using them and therefore should
be able to figure most of the stuff out for themselves (i.e. we'd only
get the real questions).

Does this seems like a worthwhile viewpoint to consider, then perhaps we
can think about starting it implement it for 7.3? (Wish I could code
better). :)

Regards and best wishes,

Justin Clift

>
> Perhaps I wasn't clear. The feature I'm proposing is this:
>
> When processing SELECT queries but before any real work has been
> done, lookup the query in a hash table. If it already exists, return the
> cached result. If it doesn't exist, execute the query and cache the
> result in the hash table. Optionally, we could not immediately cache the
> query, just increment a "frequency" counter stored in the hash table. If
> the counter goes above a certain constant, we decide that the query is
> worth caching, so we cache the full result in the hash table.
>
> When processing INSERTs, UPDATEs and DELETEs, check if the query
> would affect any of the tables for which we are maintaing this cache. If
> so, flush the cache. This ensures that we will never return invalid
> results. We could perhaps be fancy and keep stats on which columns our
> cached queries utilize and which columns the modifying query will
> affect, but that is unlikely to be an overall win.
>
> HOWEVER -- I don't see this feature as something that will appeal to,
> say, 75% of PgSQL users. If the table in question is being modified on a
> regular basis, or if a wide variety of queries are being issued, this
> cache isn't a good idea. Nevertheless, I think there are certainly some
> situations in which this cache is useful -- and furthermore, these kinds
> of "mostly read-only" situations are often where MySQL is chosen over
> PostgreSQL.
>
> Anyway, just putting this on the table -- if the consensus is that this
> isn't a very worthwhile feature, I won't bother with it.
>
> Cheers,
>
> Neil
>
> --
> Neil Conway <neilconway(at)rogers(dot)com>
> PGP Key ID: DB3C29FC
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi