Thread: PostgreSQL Anniversary Proposals -- Important Update
Folks, Wanted to update you on a few things regarding speaking at the upcoming PostgreSQL Anniversary Summit: -- 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. -- Due to e-mail issues (not fixed) we lost some proposals without a trace. So if you submitted a proposal to us, and have not already received a response, please re-submit it! We might not have seen it. -- Thanks to the tremendous generosity of Afilias, EnterpriseDB, Greenplum, and Pervasive (as well as SRA and OpenMFG), we will have the budget to help some speakers with travel funds. So if you were holding off on a proposal because you weren't sure you could afford to fly to Toronto, please send one in. Proposals can be sent through http://conference.postgresql.org/Proposals/ or directly to conference-submissions@pgfoundry.org. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
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?
regards, tom lane
Tom, On 3/17/06 7:03 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: > 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? How about future plans, so to speak? You've made some pretty significant improvements for 8.1 (virtual tuples, the caching algorithm, etc), what's on deck for 8.2 and beyond? - Luke
"Tom Lane" <tgl@sss.pgh.pa.us> wrote > > What would people like to hear about? > I am really interested in the concurrency control part of the PostgreSQL. I can see the MVCC/lock rules there, and basically I can follow them -- but there are so many if-else in the rules, so the problem always for me is: how can we gaurantee that the rules are complete and correct? So I guess I may miss a big picture somewhere. Regards, Qingqing
"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes: > "Tom Lane" <tgl@sss.pgh.pa.us> wrote >> What would people like to hear about? > I am really interested in the concurrency control part of the PostgreSQL. Hm, I already talked about that once: http://www.postgresql.org/files/developer/transactions.pdf but perhaps that's not the level of detail you are after? regards, tom lane
Tom, Luke Lonergan wrote: >>I figure I can back it up...). What would people like to hear about? > > How about future plans, so to speak? You've made some pretty significant > improvements for 8.1 (virtual tuples, the caching algorithm, etc), what's on > deck for 8.2 and beyond? I'm *really* *really* interested in making PostgreSQL to be vacuum-less. Can we have a vacuum-less PostgreSQL in the future? How? If you have any ideas, I *really* want to hear about that from you. It will be a next generation of PostgreSQL. :) Thanks. -- NAGAYASU Satoshi <nagayasus@nttdata.co.jp>
-----Original Message----- From: "Josh Berkus"<josh@agliodbs.com> Sent: 18/03/06 01:55:04 To: "pgsql-hackers@postgresql.org"<pgsql-hackers@postgresql.org> Cc: "pgsql-advocacy@postgresql.org"<pgsql-advocacy@postgresql.org> Subject: [HACKERS] PostgreSQL Anniversary Proposals -- Important Update > 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. I wouldn't mind talking (or hosting a discussion) but have been unable to think of anything that other hackers might be interestedin. I obviously can't discuss the server internals in any great depth, but if anyone wants to hear about pgadmin,pginstaller, the web infrastructure or something else I've worked on, please let me know and I'll see if I can submita proposal. > -- Thanks to the tremendous generosity of Afilias, EnterpriseDB, Greenplum, > and Pervasive (as well as SRA and OpenMFG), we will have the budget to > help some speakers with travel funds. Many thanks to them. Regards, Dave -----Unmodified Original Message----- Folks, Wanted to update you on a few things regarding speaking at the upcoming PostgreSQL Anniversary Summit: -- 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. -- Due to e-mail issues (not fixed) we lost some proposals without a trace. So if you submitted a proposal to us, and have not already received a response, please re-submit it! We might not have seen it. -- Thanks to the tremendous generosity of Afilias, EnterpriseDB, Greenplum, and Pervasive (as well as SRA and OpenMFG), we will have the budget to help some speakers with travel funds. So if you were holding off on a proposal because you weren't sure you could afford to fly to Toronto, please send one in. Proposals can be sent through http://conference.postgresql.org/Proposals/ or directly to conference-submissions@pgfoundry.org. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---------------------------(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
Satoshi Nagayasu <nagayasus@nttdata.co.jp> writes:
> I'm *really* *really* interested in making PostgreSQL to be vacuum-less.
> Can we have a vacuum-less PostgreSQL in the future? How?
I don't foresee that ever happening. AFAICS a non-vacuuming MVCC system
would have to be implemented just like Oracle (ie, rollback segments)
and as any Oracle DBA will tell you, that has plenty of drawbacks of
its own. Not to mention that Oracle probably has a few key patents
in that area.
Updating a database with transaction safety requires overhead, and
you're going to pay for that overhead somewhere. We've chosen to
pay for it via vacuum. I think that's a good system design in the
abstract --- for one thing, it keeps the overhead cost out of the
foreground transaction-processing code paths.
Of course we'll continue to whittle away at the problem of making
vacuum less objectionable --- autovacuum, reducing its i/o demand,
etc --- but I don't foresee us making a 180degree course correction
on such a fundamental design choice.
You can find plenty of discussion of this in past threads in the
pgsql-hackers archives.
regards, tom lane
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. --
Satoshi, > I'm *really* *really* interested in making PostgreSQL to be vacuum-less. > Can we have a vacuum-less PostgreSQL in the future? How? I've heard a couple other requests for dealing with vaccuum. I think a "Fixing Vacuum Round-Table" might be a valuable session if we have someone to lead it. You ready? To be clear: this is a meeting of PostgreSQL contributors. We can, and will, have sessions which are problem-solving round tables and not one-way presentations with slides. Also, Tom, here's one which might be good: a "TODO" round-table led by you and Bruce, where we talk about the todo list, the things that are likely to get done, the things which aren't, what else should be on there, etc. Another talk I'd like to see ... but I don't know who would give it ... would be one on "Exotic PostgreSQL" which would survey Time Travel, TelegraphCQ, Postgres-R, QBE, etc. -- Josh Berkus Aglio Database Solutions San Francisco
Ühel kenal päeval, L, 2006-03-18 kell 12:38, kirjutas Rod Taylor: > 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. ... > In short, tell us why the hammer of PostgreSQL makes a bad screw driver. Yup. My own ideas for a proposal have mostly revolved aroud topic "Why postgresql sucks", and how to persuade the core to both understand the issues and accept solutions for fixing these. That means discussing areas where there is much room for improvement: 1) OLTP 2) 24/7 3) OLAP I have written code (mutually non-blocking vacuum) and proposals on lists (online index creation, archive tables) which would probably help a lot in each of these areas, once developers start believing that actual problems exist ;). And of course one will always want better introspaction into the backends. -------Hannu
Qingqing Zhou wrote: > I am really interested in the concurrency control part of the PostgreSQL. I > can see the MVCC/lock rules there, and basically I can follow them -- but > there are so many if-else in the rules, so the problem always for me is: how > can we gaurantee that the rules are complete and correct? So I guess I may > miss a big picture somewhere. Are you talking specifically about the stuff in tqual.c? If so, I agree that there doesn't seem to be enough description of how they work, much less formal proof that they are complete or correct. I don't know if it is enough material for a "presentation" though. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Dave, > I wouldn't mind talking (or hosting a discussion) but have been unable to > think of anything that other hackers might be interested in. I obviously > can't discuss the server internals in any great depth, but if anyone wants > to hear about pgadmin, pginstaller, the web infrastructure or something > else I've worked on, please let me know and I'll see if I can submit a > proposal. Well, aside from anything else, we seem likely to have you, Devrim, Magnus and maybe even Robert Treat there (Robert?). Which would mean a good time for a meeting of the Web Team, yes? "Plans for the PostgreSQL Web Site (bring your wish list)" -- Josh Berkus Aglio Database Solutions San Francisco
Hi, On Sun, 2006-03-19 at 11:34 -0800, Josh Berkus wrote: > Well, aside from anything else, we seem likely to have you, Devrim, > Magnus and maybe even Robert Treat there (Robert?). Which would mean > a good time for a meeting of the Web Team, yes? It seems that I'll be there, and yes, a PostgreSQL.org web development session will be cool. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PL/php, plPerlNG - http://www.commandprompt.com/
"Tom Lane" <tgl@sss.pgh.pa.us> wrote > > Hm, I already talked about that once: > http://www.postgresql.org/files/developer/transactions.pdf > but perhaps that's not the level of detail you are after? > Yeah, I've read the presentation -- and yes, that's not the level I am after. Actually, I guess the completeness problem can be clarified with a table: a_complete_and_clear_division_of_transaction_time SatisfySnapShot Y Y N N ... SatisfyVacuum 1 2 2 3 ... Not sure how to give the corrctness proof -- maybe if the "a_complete_and_clear_division_of_transaction_time" is designed well enough, we can find some consistency? And as Alvaro suggested, maybe that's too narrow topic for a presentation -- so if the above idea is in the right track, I'd like to write an initial document (so you guys can modify it) if nobody is interested in doing that. Regards, Qingqing
Josh, Josh Berkus wrote: > I've heard a couple other requests for dealing with vaccuum. I think a > "Fixing Vacuum Round-Table" might be a valuable session if we have someone to > lead it. You ready? If required. I want to know how people think about vacuum, and many ideas around vacuum. > To be clear: this is a meeting of PostgreSQL contributors. We can, and will, > have sessions which are problem-solving round tables and not one-way > presentations with slides. Cool. Sure, it will be a good chance to discuss about the future direction of PostgreSQL, and I'm very happy if I can join to many discussions. > Also, Tom, here's one which might be good: a "TODO" round-table led by you and > Bruce, where we talk about the todo list, the things that are likely to get > done, the things which aren't, what else should be on there, etc. It's very interesting. I want this round-table to be an introduction to the newbie hackers (like me). -- NAGAYASU Satoshi <nagayasus@nttdata.co.jp>
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
Tatsuo, > I'm wondering if this was approved or not... We haven't approved *anything* yet. The deadline was just Saturday, and I'm still keying stuff into the conference management system. -- Josh Berkus Aglio Database Solutions San Francisco