|
Home > Archive > PostgreSQL Hacks > March 2006 > Re: PostgreSQL Anniversary Proposals -- Important Update
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: PostgreSQL Anniversary Proposals -- Important Update
|
|
| Rod Taylor 2006-03-19, 11:10 am |
| On Fri, 2006-03-17 at 22:03 -0500, Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>
> 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.
--
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
| |
| Jim C. Nasby 2006-03-21, 3:33 am |
| On Sat, Mar 18, 2006 at 12:38:30PM -0500, Rod Taylor wrote:
> 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.
FYI, that's exactly what http://rrs.decibel.org does (yeah, I know,
viewcvs is down... :( )
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
|
|
|
|
|