Re: PostgreSQL Anniversary Proposals -- Important Update

On Fri, 2006-03-17 at 22:03 -0500, Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> > -- There are only 13 days left to submit a proposal. Please do so. We'd
> > rather not be forced into a last-minute rush to evaluate all of the stuff
> > in April. Remember this is a "family" event so you don't have to have all
> > of your materials together before you send something. Heck, if you have
> > an idea for a talk you'd really, really, really like to see and can't give
> > it, send it anyway. We may be able to find a speaker.
>
> Speaking of which, I've been trying to think of a talk proposal and am
> not coming up with anything that seems terribly sexy. I've talked a
> couple times about the planner and am afraid people would be bored by
> that again. I'd be willing to hold forth on almost any part of the
> backend system design (a bold claim, but with three months to prepare
> I figure I can back it up...). What would people like to hear about?

This will, presumably, be a very PostgreSQL friendly group so a sales
pitch isn't really required.

How about the opposite? Tom Lanes list of areas that PostgreSQL does a
poor job and a detailed explanation as to how that design decision or
limitation came about as well as what can (or cannot) be done to fix it.

I know there are a large number of items on your personal TODO and
CANNOTDO lists that have either had very brief or no discussion in the
mailing lists. Usage patterns that PostgreSQL simply does not handle
well for not-so-obvious reasons and how to either work around those
limitations as a user or changes that could be made to fix them.

One example might be a 'self-aggregating' structure. Start with one
entry per minute in a table indexed by time. After 2 weeks passes, the
per-minute data is aggregated and the single entry at the start of the
day is updated with the aggregate value with the other entries for the
day being removed. I believe this can cause significant index bloat
since it results in a few entries per page in the index.

Using 2 structures via inheritance with one holding the per-minute data
and one holding the per-day aggregates is much better.

In short, tell us why the hammer of PostgreSQL makes a bad screw driver.

--