Re: PostgreSQL Anniversary Proposals -- Important Update
От | Rod Taylor |
---|---|
Тема | Re: PostgreSQL Anniversary Proposals -- Important Update |
Дата | |
Msg-id | 1142703510.802.57.camel@home обсуждение исходный текст |
Ответ на | Re: PostgreSQL Anniversary Proposals -- Important Update (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PostgreSQL Anniversary Proposals -- Important Update
Re: PostgreSQL Anniversary Proposals -- Important Update |
Список | pgsql-hackers |
On Fri, 2006-03-17 at 22:03 -0500, Tom Lane wrote: > Josh Berkus <josh@agliodbs.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. --
В списке pgsql-hackers по дате отправления: