Re: [HACKERS] PostgreSQL Anniversary Proposals -- Important Update
-Original Message- From: Josh Berkusjosh@agliodbs.com Sent: 18/03/06 01:55:04 To: pgsql-hackers@postgresql.orgpgsql-hackers@postgresql.org Cc: [EMAIL PROTECTED][EMAIL PROTECTED] 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 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. -- 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 [EMAIL PROTECTED] -- --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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] OSX intel
Has anyone built postgresql on this platform ? Does it work ? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] OSX intel
On Mar 18, 2006, at 22:17 , Dave Cramer wrote: Has anyone built postgresql on this platform ? Yes, there have been reports that it builds. You can check the archives for details. Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL Anniversary Proposals -- Important
Satoshi Nagayasu [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PostgreSQL Anniversary Proposals -- Important Update
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. -- ---(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
Re: [HACKERS] Automatically setting work_mem
Tom, On 3/17/06 9:59 PM, Tom Lane [EMAIL PROTECTED] wrote: This would buy what exactly? I guess you didn't read the other 80% of the post. In short, faster performance through more aggressive runtime compilation. A JIT for the database kernel. It's not like I'm on shaky ground here - other commercial DBMS have done it for over a decade. - Luke ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Automatically setting work_mem
Tom, On 3/17/06 12:18 PM, Tom Lane [EMAIL PROTECTED] wrote: One user with ability to enter arbitrary SQL commands can *always* blow your resource planning away. Blaming such things on work_mem is seriously misguided. Agreed - that's why we need to split this discussion into the two categories of (1) scheduling for concurrency protection and (2) dynamic resource allocation. Topic (1) is best handled by statement queuing IMO and as demonstrated by other commercial DBMS. This allows queues of different resource demands to be used for ensuring that statements can not over consume memory, temp disk, etc, and that queries with large requirements for some or all of those can be allocated as much as possible, and those with smaller requirements will be run (likely at much higher rates) while longer running queries take up the larger resource pool. (2) is what this thread is mostly talking about, and the dynamic allocation of memory to plan nodes (sort, hash) needs to be done so that we are much more efficient in memory footprint and give more where it's needed. (2) will require some way of putting an overall memory footprint to a statement, then sub-allocating within it. I suggest we assume that the overall memory footprint is constrained somehow, perhaps another GUC that describes a per statement maximum memory consumption, then at plan time we determine the sub-allocations that best achieve the plan. This would fit within a scheme for (1) when we develop one. - Luke ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] PostgreSQL Anniversary Proposals -- Important
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] OSX intel
On Sat, 2006-03-18 at 22:36 +0900, Michael Glaesemann wrote: Yes, there have been reports that it builds. You can check the archives for details. Are we prepared to declare that OS/X on Intel is an officially supported platform for the 8.1 release series? If so, we should add that information to the list of supported platforms for the REL8_1_STABLE branch. Given how (relatively) popular OS/X Intel machines will before the 8.1 branch is retired, we should at least clarify the status of the OS/X Intel port. BTW, I notice that there isn't an OS/X Intel machine in the buildfarm. Does anyone have access to one? -Neil ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] OSX intel
On Mar 18, 2006, at 1:39 PM, Neil Conway wrote: On Sat, 2006-03-18 at 22:36 +0900, Michael Glaesemann wrote: Yes, there have been reports that it builds. You can check the archives for details. Are we prepared to declare that OS/X on Intel is an officially supported platform for the 8.1 release series? If so, we should add that information to the list of supported platforms for the REL8_1_STABLE branch. Given how (relatively) popular OS/X Intel machines will before the 8.1 branch is retired, we should at least clarify the status of the OS/X Intel port. BTW, I notice that there isn't an OS/X Intel machine in the buildfarm. Does anyone have access to one? I'm running regressions on one with the buildfarm code. I just need to get around to plugging it back into the buildfarm. Cheers, Steve ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Automatically setting work_mem
Luke Lonergan wrote: Tom, On 3/17/06 9:59 PM, Tom Lane [EMAIL PROTECTED] wrote: This would buy what exactly? I guess you didn't read the other 80% of the post. In short, faster performance through more aggressive runtime compilation. A JIT for the database kernel. It's not like I'm on shaky ground here - other commercial DBMS have done it for over a decade. In exactly a fortnight from today, I'll repost my suggestion to rewrite the backend in Java ;-) Regards, Thomas Hallgren ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] FW: PGBuildfarm member snake Branch HEAD Status changed from OK to Check failure
Seeing failure on 8.1 as well. BTW, I keep forwarding these, but is there any need? Are enough hackers on the status change lists anyway? /D -Original Message- From: PG Build Farm[EMAIL PROTECTED] Sent: 18/03/06 02:13:19 To: [EMAIL PROTECTED][EMAIL PROTECTED], [EMAIL PROTECTED][EMAIL PROTECTED] Subject: PGBuildfarm member snake Branch HEAD Status changed from OK to Check failure The PGBuildfarm member snake had the following event on branch HEAD: Status changed from OK to Check failure The snapshot timestamp for the build that triggered this notification is: 2006-03-18 02:00:00 The specs of this machine are: OS: Windows / Server 2003 SP1 Arch: i686 Comp: gcc / 3.4.2 For more information, see http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=snakebr=HEAD ---BeginMessage--- The PGBuildfarm member snake had the following event on branch HEAD: Status changed from OK to Check failure The snapshot timestamp for the build that triggered this notification is: 2006-03-18 02:00:00 The specs of this machine are: OS: Windows / Server 2003 SP1 Arch: i686 Comp: gcc / 3.4.2 For more information, see http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=snakebr=HEAD ---End Message--- ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PostgreSQL Anniversary Proposals -- Important Update
Ü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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PostgreSQL Anniversary Proposals -- Important Update
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 Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
