Re: [HACKERS] Change request ...
Martijn van Oosterhout wrote: On Thu, Sep 27, 2007 at 02:48:52PM +0530, Anoo Sivadasan Pillai wrote: Description : I have two tables with the same data , While I issue an update command to increment the value of a unique field by 1, the statement fails in one table and will succeed in the other table. Following is the script to reproduce the behaviour. Correct. Unique constraints are not deferrable. I'm sure there are people who would like it fixed, but there is currently not even a proposal on how to do it. It's a hard problem, for which there are well-known work-arounds. In practice this problem don't come up too often. It's been on the TODO list for at least 5 years... Wow, I was not aware of this limitation. MySQL hacks around this issue by allowing an ORDER BY in UPDATE (and DELETE) statements. regards, Lukas ---(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] EXPLAIN omits schema?
Stephen Frost wrote: * Dave Page ([EMAIL PROTECTED]) wrote: /* We only show the rel name, not schema name */ relname = get_rel_name(rte-relid); Anyone know why? This seems like a bug to me given the ambiguity of possible output. I'd assume it's to keep the explain output smaller with the expectation/assumption that in general you're going to know. A possible work-around would be to just always provide table aliases for your queries, as those are shown in the explain. I am hoping that once we have WITH RECURSIVE, we could optionally provide a normalized dump into a table of the EXPLAIN output, that could then be easily connected the the old output using WITH RECURSIVE. regards, Lukas ---(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] EXPLAIN omits schema?
Tom Lane wrote: I agree with the idea of having an option to get EXPLAIN's output in an entirely different, more machine-readable format. Not wedded to XML, but I fear that a pure relational structure might be too strict --- there's a lot of variability in the entries already. XML also could deal naturally with nesting, whereas we'd have to jump through hoops to represent the plan tree structure in relational form. Which was my point regarding needing WITH RECURSIVE to make this truely useful. XML output is nice, but only as an addition imho. Then again it would indeed be quite useful for external development tools. regards, Lukas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Using the GPU
Gregory Stark wrote: Billings, John [EMAIL PROTECTED] writes: Does anyone think that PostgreSQL could benefit from using the video card as a parallel computing device? I'm working on a project using Nvidia's CUDA with an 8800 series video card to handle non-graphical algorithms. I'm curious if anyone thinks that this technology could be used to speed up a database? If so which part of the database, and what kind of parallel algorithms would be used? There has been some interesting research on sorting using the GPU which could be very interesting for databases. Without knowing a thing about all of this, my first thought it might be useful for GIS and things of that sort. regards, Lukas ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Planning large IN lists
Neil Conway wrote: Clearly, the current approach is fine when the array is small -- perhaps for arrays above a certain number of elements, we could switch to randomly sampling array elements, estimating their selectivities, and then using that information to infer the estimated selectivity of the entire array expression. That seems fairly crude, though: does anyone have any better ideas? Optimizer hints in SQL /me ducks and runs for cover. regards, Lukas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Feature lists for 8.3 and 8.4
Abraham, Danny wrote: Hi, I am migrating from Sybase to Postgres. trying to get a hold on the issue of future releases feature list. 1. Where can I find the feature list for 8.3 ? When is it expected? 2. And for 8.4? There are various places to look for this kind of information, but probably the easiest to digest is looking at the todo lists on the wiki: http://developer.postgresql.org/index.php/Todo:Contents regards, Lukas PS: Since this is a fairly new effort, if you have any hints on how to improve things, let us know. ---(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] Managing the community information stream
Jim Nasby wrote: On May 8, 2007, at 9:50 AM, Andrew Sullivan wrote: On Mon, May 07, 2007 at 07:36:55AM -0500, Jim Nasby wrote: Instead, if all feature requests are tracked then users can vote on what's most important to them. I am sympathetic to the issues you and Andrew are describing (I understand Bruce's stream analogy, but I think Andrew is right that from the user's point of view, it's not usable). But I am not convinced that users voting on desired features will get us the users' desired features. The features we get are mostly the features that have attracted developers. The method by which that attraction happens is interesting, but I don't think it's democratic. It may... it may not. If a high-demand feature sits around long enough it could well attract someone capable of working on it, but who isn't a current contributor. Or it could attract a bounty. Also keep in mind that many of the developers are working for companies that ensure that resources get allocated according to what users need and not only by what developers are motivated to work on. That being said, it seems obvious that so far PostgreSQL has been mainly driven by what developers feel like implementing. I think this is also what ensured the high level of standards compliance of PostgreSQL, since features were tailored for experienced DBA types, rather than end users that are less experienced in how to leverage these standards. regards, Lukas ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Managing the community information stream
Hi, guess I missed hackers on my initial reply. So I am re-sending the reply I send to Joshua based on the reply I send to him in regards to a hackers@ posting. Read below. regards, Lukas Joshua D. Drake wrote: That being said, it seems obvious that so far PostgreSQL has been mainly driven by what developers feel like implementing. I think this is also what ensured the high level of standards compliance of PostgreSQL, since features were tailored for experienced DBA types, rather than end users that are less experienced in how to leverage these standards. PostgreSQL has *never* been developed with the DBA in mind. Keep in mind that most of the postgresql developers have *zero* real world experience. Nor do they run postgresql themselves in real world production environments. Well, certainly more with a DBA in mind than a middle tier developer? regards, Lukas PS: Did you mean to only reply to me? ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Reducing stats collection overhead
Tom Lane wrote: The first design that comes to mind is that at transaction end (pgstat_report_tabstat() time) we send a stats message only if at least X milliseconds have elapsed since we last sent one, where X is PGSTAT_STAT_INTERVAL or closely related to it. We also make sure to flush stats out before process exit. This approach ensures that in a lots-of-short-transactions scenario, we only need to send one stats message every X msec, not one per query. The cost is possible delay of stats reports. I claim that any transaction that makes a really sizable change in the stats will run longer than X msec and therefore will send its stats immediately. Cases where a client does a small transaction after sleeping for awhile (more than X msec) will also send immediately. You might get a delay in reporting the last few transactions of a burst of short transactions, but how much does it matter? So I think that complicating the design with, say, a timeout counter to force out the stats after a sleep interval is not necessary. Doing so would add a couple of kernel calls to every client interaction so I'd really rather avoid that. Well and if this delaying of updating the stats has an effect on query time, then it also increases the likelihood of going past the X msec limit of that previously small query. So its sort of self fixing with the only risk of one query getting overly long due to lack of stats updating. regards, Lukas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Feature freeze progress report
Alvaro Herrera wrote: Yeah; the agreement we had was that 8.3 would be a short release. So if we're going to take too long to review and apply the outstanding patches we have, we should rather push them to 8.4, get 8.3 released quickly and then go on with the regular annual release. The postponed patches can be reviewed and committed early in 8.4, instead of at the last minute in 8.3. Sounds like a smarter, safer move. Hmm, I do not have an overview on this, but like Alvaro mentions, the shorter release cycles for 8.3 was done because we felt that a number of patches that were originally slated for 8.2 were almost but not quite ready for 8.2. So are all of those patches from back then ready to go into 8.3? If not then it would indicate that fast tracking a release cycle for patches there are not quite there yet is not paying off? Otherwise, if all/most of the patches originally planned for 8.2 have made it into 8.3, everything is good. If new additions are not yet ready then they will just get bumped to 8.4, just like the changes that got bumped to 8.3. regards, Lukas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Feature freeze progress report
Stefan Kaltenbrunner wrote: 2) Introduce a new patch management system. I suggest a web interface through which patches be submitted. This would assign them an ID number, and forward them to the patches list. The system would track any responses to the initial email, logging the thread automatically and making it available through the web interface. Posts from trusted/experienced developers might be highlighted so that committers can see at a glance if any of the more experienced guys have commented on the patch yet. A status flag could easily include a status flag to mark them as won't accept, committed, under review or under revision. If left at under review for too long, the patch might be highlighted, and if at under revision for too long, the patch author might be automatically requested to send a status report. this sounds like trying to reinvent a real bugtracking system with an email interface ... I think the angle of this suggestion is to approach things from the perspective of trying to automate more according to how people are currently working instead of shoehorning an existing solution. It seems that most folks on -hackers prefer email based systems. The proposals sounds like it would not change anything much for people who choose to ignore the web interface and as such it has some appeal to it. regards, Lukas ---(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
[HACKERS] Wishlist updates
Hello, Currently on the wishlist [1] we have the following items as posponed: * WITH RECURSIVE hierarchical queries (Gregory Stark) * SQL:2003 windowing queries (Gavin) * Fix permissions properly on custom GUC vars (Andrew Dunstan) * Create a mechanism for plperl to load modules safely (Andrew Dunstan) * Notification payload messages (Andrew Dunstan) * Better handling of partitioning (Nikhils) I have already moved updatable views to the newly created 8.4 wishlist [2]. Please let me know if any item is infact not posponed or should be moved to the 8.4 wishlist. regards, Lukas [1] http://developer.postgresql.org/index.php/Todo:WishlistFor83 [2] http://developer.postgresql.org/index.php/Todo:WishlistFor84 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] who gets paid for this
Andrew Dunstan wrote: Tom Lane wrote: Even more to the point, getting paid for has almost nothing to do with has commit privileges. At least on this project. Darn. So the cheque isn't really in the mail? I think his question was just which ratio of developers works on PostgreSQL on company time. regards, Lukas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Developer TODO List as a PostgreSQL DB
Andrew Dunstan wrote: Chad Wagner wrote: There is some point in putting it in a wiki where we can gather relevant documents, links to discussions etc. That's why the developers' wiki was established, AIUI. To be honest, it may be adequate to maintain this solely through the Wiki. The only thing I see lacking is specifically who is handling tasks, and what release it is planned for. Perhaps, I am just looking in the wrong place? There's a good reason this information is missing: it doesn't exist. Please, like I said, have a look at recent discussions. Maybe we need some extra FAQs, like: . Why do you still use CVS instead of insert favorite SCM system here? . Why don't you use bug tracking software? . Where do I find out when insert desired feature here will be in a release? yeah .. would be a good idea .. with some links to key posts in the archive .. would be much less work than replying all the time .. and would also make it easier for new comers to not burn their fingers at rehashing things needlessly .. regards, Lukas ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Simple Column reordering
Simon Riggs wrote: If this is standards-breaking as you say, I would withdraw immediately. I checked the SQL standard and could not see how this would do so. The standard states SELECT * would return columns in order; it doesn't say what that order should be, nor does CREATE TABLE enforce the ordering to be the same as it has specified, AFAICS. Please correct me and I will withdraw. Practical issues seem far stronger drivers than standards issues here, which is why the parameter would default=off. I did not follow the entire thread. I just wanted to point out that IIRC MS SQL Server (and maybe also Sybase) do automatically optimize the internal order of how columns are stored to move fixed length (which also means non NULLable for these two servers) columns to the left. Maybe this will serve as a reference point (not necessarily for standards compliance of course). regards, Lukas ---(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] Simple Column reordering
Bruce Momjian wrote: Lukas Kahwe Smith wrote: Simon Riggs wrote: If this is standards-breaking as you say, I would withdraw immediately. I checked the SQL standard and could not see how this would do so. The standard states SELECT * would return columns in order; it doesn't say what that order should be, nor does CREATE TABLE enforce the ordering to be the same as it has specified, AFAICS. Please correct me and I will withdraw. Practical issues seem far stronger drivers than standards issues here, which is why the parameter would default=off. I did not follow the entire thread. I just wanted to point out that IIRC MS SQL Server (and maybe also Sybase) do automatically optimize the internal order of how columns are stored to move fixed length (which also means non NULLable for these two servers) columns to the left. Maybe this will serve as a reference point (not necessarily for standards compliance of course). And that optimized ordering shows up with SELECT *? no .. like i said its just the internal order .. I think I learned this piece of information from reading SQL performance tuning by Peter and Trudy .. dont have the book here right now to give a page number. regards, Lukas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Re: 5 Weeks till feature freeze or (do you know where your patch is?)
Joshua D. Drake wrote: Hello, 5 weeks to feature freeze folks. Please provide updates including if you think you will have a patch submitted before feature freeze. Be realistic, if you can't make it -- say so. Alvaro Herrera: Autovacuum improvements (maintenance window etc..) Gavin Sherry: Bitmap Indexes (on disk), possible basic Window functions Greg Stark: WITH/Recursive Queries? Andrei Kovalesvki: Some Win32 work with Magnus Magnus Hagander: VC++ support (thank goodness) Heikki Linnakangas: Vacuum for Bitmap Indexes, Group Index Tuples Oleg Bartunov: Tsearch2 in core Neil Conway: Patch Review (including enums), pg_fcache PeterE: XML ITAGAKI Takahiro: Dead space map, load distributed checkpoints Stephen Frost: Default permission per object/schema Tom Lane: Cost based functions, operator overhaul, Plan Invalidation? Simon Riggs: HOT ( you know he just is ) Pavan Deolasee: HOT ( never met him ) Teodor Sigaev: Tsearch2 in core (with Oleg) Jeff Davis: Synchronized scanning Henry Hotz: GSSAPI (with Magnus) Andrew Dunstan: Something with COPY? Andrew? David Fetter: Arrays of compound types Looking for updates on Updateable views. Anyone? Bueller? Afaik Bernd is working in this one and he is targetting 8.4 Looks like we are doing redundant work here: http://developer.postgresql.org/index.php/Todo:WishlistFor83 Where/how do you maintained your todo list Joshua? Would love to join forces on this one .. especially since I send out emails to many of the above noted people. If we both send emails to everybody they might get ticked off .. regards, Lukas ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] SCMS question
Hey, Anyone who followed the thread willing to list the mentioned requirements as well as the pro's and con's of the differnent options in the developer wiki [1]? I think this would help a lot in making a decision and it could be a lot of help for other OSS projects considering to switch. If you do not have an account with write access, just open an account on the wiki and email Greg to get your ACL's upgraded so you can write into the wiki. I can also try to work on this a bit over the weekend. regards, Lukas [1] http://developer.postgresql.org ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] wishlist items ..
Hannu Krosing wrote: Ühel kenal päeval, L, 2007-02-17 kell 13:35, kirjutas Lukas Kahwe Smith: Lukas Kahwe Smith wrote: I just wanted to bring up the wishlist todo items: http://developer.postgresql.org/index.php/Todo:WishlistFor83 What does/did the row Clustered/replication solutions refer to ? there was some discussion early on in 8.3 scoping to add some out of the box solutions for clustering and replication in order to reduce the barrier to entry for people who require such features. regards, Lukas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Plan invalidation design
Tom Lane wrote: Lukas Kahwe Smith [EMAIL PROTECTED] writes: I remember that there was discussion about invalidating plans who's estimated cost turn out to be severely off when executed. That's something we might think about after the infrastructure is in place. But the question to answer is why the re-plan won't yield just the same plan as before. Yeah, also invalidating plans like this only really makes sense once we have the ability to keep multiple plans around for different sets of parameters. Otherwise we could also end up in a situation where after every execution we determine that a re-plan is necessary because the parameters used differ in distribution. regards, Lukas ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Plan invalidation design
Tom Lane wrote: place. But the question to answer is why the re-plan won't yield just the same plan as before. oh and when the estimated cost repeatedly do not match the actual cost, we of course want to generate an email with all relevant information that is send to this list ;) regards, Lukas ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] wishlist items ..
Lukas Kahwe Smith wrote: I just wanted to bring up the wishlist todo items: http://developer.postgresql.org/index.php/Todo:WishlistFor83 I have gotten feedback from most items on the list and I have updated the list accordingly. Maybe a few of the items can even be moved to Completed already. Obviously all items under Perhabs could use some helping hands. Also note that I have placed Plan invalidation under Perhabs since Heikki said he is giving his other items priority and I have not gotten feedback from Tom. Also note that Alvaro could use some help for autovac even though he is still quite hopeful to make it on time. Finally Pavel is looking for feedback and testing for the SQL/PSM support. The 4 items I have not gotten feedback on are as follows: * WITH RECURSIVE hierarchical queries (Gregory Stark) * Better handling of partitioning * Hot Updates (Pavan) * Reuse of index tuples (Simon Riggs) I have emailed Gregory, Pavan and Simon only 2 days ago, so I am not suprised to not haven gotten feedback yet. Overall it looks quite well! regards, Lukas PS: Let me know if you feel I could improve this service in any way. ---(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] Plan invalidation design
Tom Lane wrote: Relcache inval casts a fairly wide net; for example, adding or dropping an index will invalidate all plans using the index's table whether or not they used that particular index, and I believe that VACUUM will also result in a relcache inval due to updating the table's pg_class row. I think this is a good thing though --- for instance, after adding an index it seems a good idea to replan to see if the new index is useful, and replanning after a VACUUM is useful if the table has changed size enough to warrant a different plan. OTOH this might mean that plans on a high-update-traffic table never survive very long because of autovacuum's efforts. If that proves to be a problem in practice we can look at ways to dial down the number of replans, but for the moment I think it's more important to be sure we *can* replan at need than to find ways to avoid replans. I remember that there was discussion about invalidating plans who's estimated cost turn out to be severely off when executed. That is probably a more reliable metric (than invalidating with every VACCUM - unless of course the amount of changed rows is considered), though it will probably put a fixed overhead on all relevant queries. So it might not be feasible. Of course this checking after a query runs longer than expected also means that at least one execution will in fact have to run slow instead of preempting this from happening at all. Also while not directly related it might be thing to keep in mind. It would also be cool to support multiple plans for different sets of parameters, since obviously the data distribution and therefore the optimal plan will potentially vary greatly with different parameters. regards, Lukas PS: I moved Plan invalidation to confirmed on the wishlist .. ---(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
[HACKERS] OT: IRC nick to real world mapping
Hi, I know this is slightly off topic, but I hope still useful enough to not get my head cut off for posting this: http://developer.postgresql.org/index.php/IRC2RWNames This is essentially a mapping of IRC nicks to real world names. While maintaining the wishlist I keep forgetting the IRC nicks of people to map to from the wishlist real world names. But I think this could be generally useful, so I started the list. Please mail me off list with whatever editions people have. regards, Lukas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] OT: IRC nick to real world mapping
Bruce Momjian wrote: Lukas Kahwe Smith wrote: Hi, I know this is slightly off topic, but I hope still useful enough to not get my head cut off for posting this: http://developer.postgresql.org/index.php/IRC2RWNames This is essentially a mapping of IRC nicks to real world names. While maintaining the wishlist I keep forgetting the IRC nicks of people to map to from the wishlist real world names. But I think this could be generally useful, so I started the list. Please mail me off list with whatever editions people have. Ah, excellent. Should we put this in the IRC topic line? if there is still some space in the topic ... sure! regards, Lukas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] wishlist items ..
Aloha, I just wanted to bring up the wishlist todo items: http://developer.postgresql.org/index.php/Todo:WishlistFor83 All items have a name behind them aside from Better handling of partitioning. Does anyone feel responsible for handling that one? Anyways I would appreciate it if people who's name is behind each of the items to either mail this list or me directly to let me know if they are still handling this item for 8.3 or not. I will then make sure to update the list accordingly. The applies if an item is missing. For convenience here is the current state: The following items are on the table for 8.3: * On disk bitmap index (Gavin) * WITH RECURSIVE hierarchical queries (Gregory Stark) * Better handling of partitioning * SQL:2003 windowing queries (Gavin) * Improvements to autovac (Alvaro Herrera) * SQL/XML support per SQL:2003 (Peter) * Notification payload messages (Andrew Dunstan) * Fix permissions properly on custom GUC vars (Andrew Dunstan) * Create a mechanism for plperl to load modules safely (Andrew Dunstan) * Plan invalidation (Tom, Heikki) * Tsearch2 in core (Teodor Sigaev, Oleg Bartunov) * Grouped Index Tuples (Heikki) * Hot Updates (Pavan) * Reuse of index tuples (Simon Riggs) * ENUM (Tom Dunstan) * GENERATED/IDENTITY patches (Zoltan Boszormenyi) * Updatable VIEWs (Bernd) Postponed The following features are unlikely to make it into 8.3 at this point: * SQL/PSM support per SQL:2003 (Pavel) * Clustered/replication solutions Completed * Operator family rewrite (Tom) regards, Lukas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] wishlist items ..
Pavel Stehule wrote: Postponed The following features are unlikely to make it into 8.3 at this point: * SQL/PSM support per SQL:2003 (Pavel) * Clustered/replication solutions SQL/PSM is available (without resignal stmt and extended diagnostic stmt). Some people work on doc translation to english. experience I waiting for real using and real experience with it. ok thanks .. updated on the wishlist .. I also got feedback from Gavin, which is also incorporated already. regards, Lukas ---(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] How to gain R/W access to developers wiki?
Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Surely, I've created one (nickname: Nikolay) and are trying to do things being logged in :-) You should be able to edit now with the Nikolay account. If anyone else is having problems, please send me an email. I'll work on documenting this better when I return, but for those with psql access, just add the user in question to the user_groups table with pgdev acceess. Alot of people are having trouble editing pages on the wiki. They keep coming to me too :) There seems to be something foobar with the permissions that are being set when users create new accounts ..? Greg: could you have a look into this? regards, Lukas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Updateable cursors
Joshua D. Drake wrote: Lukas Kahwe Smith wrote: Joshua D. Drake wrote: Great! I will put it on my, Remember to bug Arul list :) Hey Joshua, could you put this stuff here: http://developer.postgresql.org/index.php/Todo:WishlistFor83 Sure if you bother to unlock the page for me ;) hmm .. i am not aware of having a lock. i dont know mediawiki all that well, but clicking around i could not find anything. IIRC someone else also had issues editing pages on the wiki. regards, Lukas ---(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] Updateable cursors
Joshua D. Drake wrote: Great! I will put it on my, Remember to bug Arul list :) Hey Joshua, could you put this stuff here: http://developer.postgresql.org/index.php/Todo:WishlistFor83 I will try to find some time during this week (likely on the weekend) to also try and figure out if these items are real and if the people still think they can do them for 8.3 .. your additions would be most helpful. regards, Lukas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.3 pending patch queue
Andrew Dunstan wrote: The latter does not exist, AFAIK. Before feature freeze for cycle X, we don't usually hold patches for release X+1, as I understand it. In general, we should try to hold patches as little amount of time as possible. That way they don't go stale as easily. I did not follow this thread closely, but it would be nice if someone could compile all of these defacto standards into a wiki page. regards, Lukas PS: Dont me make read this entire thread just to create this wiki page myself :P ---(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] TODO: Add a GUC to control whether BEGIN inside
Alvaro Herrera wrote: news.postgresql.org wrote: While we are on the topic, I have implemented a poor mans nested transaction feature into my database access layer. essentially subsequent calls to begin a transaction after the initial begin simply increase an internal counter and set a savepoint. as you commit the transactions the counter is decreased and the savepoints are released. maybe this could be implemented inside postgresql to make the life of modular programmers easier? Yeah, it's called SAVEPOINT foo and RELEASE foo. Err, I think you misunderstood what I said. My implementation uses SAVEPOINTs already. The point is having some API where you do not have to care of you are already in a transaction or not. Depending on if you are it will either open a new transaction or simply place a savepoint. with the following invented commands: MBEGIN FOO1 // open transaction; set counter to 1 MBEGIN FOO2 // set savepoint FOO2; set counter to 2 MBEGIN FOO3 // set savepoint FOO3; set counter to 3 MROLLBACK FOO3 // rollback to FOO3; set counter to 2 MCOMMIT FOO2 // release FOO2; set counter to 1 MCOMMIT FOO1 // commit regards, Lukas regards, Lukas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
Tom Lane wrote: Lukas Kahwe Smith [EMAIL PROTECTED] writes: Err, I think you misunderstood what I said. My implementation uses SAVEPOINTs already. The point is having some API where you do not have to care of you are already in a transaction or not. It's not that hard, is it? if (PQtransactionStatus(conn) == PQTRANS_IDLE) PQexec(conn, BEGIN); else PQexec(conn, SAVEPOINT foo); Its not exactly convenient either, especially in the case of modular code that may be developed by different people. Anyways, like I said I have a solution in my framework to make life of module developers easier. Obviously proper nested transactions would be the ideal, but so it goes. I was just throwing this out here when I saw Peter's comment. regards, Lukas ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Release 8.2.0 done, 8.3 development starts
Bruce Momjian wrote: [1] http://developer.postgresql.org/index.php/Todo:WishlistFor83 That looks helpful. Ok good :) Seriously though, please slap me when things are wrong, not assigned yet to the correct person .. there was a bit of guess work involved with some of the points .. especially with the names. I will let things sit like they are for 1-2 weeks and I will probably try to get a hold off each of the people still assigned to items then to confirm that they are actually targeting the feature for 8.3 .. or am I duplicating Bruce's efforts when I do this? regards, Lukas ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Release 8.2.0 done, 8.3 development starts
Hi, I just collected all the items mentioned in this thread as well as what people quickly came up with on IRC and put it on a list in the developer wiki [1]. I tried to put names and links behind the items where ever possible. Let me know if there is something missing or if you know any other information (links, names) etc. that should be mentioned. The list is kinda scary long .. regards Lukas [1] http://developer.postgresql.org/index.php/Todo:WishlistFor83 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Companies Contributing to Open Source
Hi, I think another point you need to bring out more clearily is that the community is also often miffed if they feel they have been left out of the design and testing phases. This is sometimes just a reflex that is not always based on technical reasoning. Its just that as you correctly point out are worried of being high-jacked by companies. regards, Lukas ---(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] Companies Contributing to Open Source
Joshua D. Drake wrote: O.k. in all Bruce I like your article but I must admit it seems to take a The community is god perspective and that we must all bend to the will of said community. The community could learn a great deal from adopting some of the more common business practices when it comes to development as well. In short, I guess I think it is important to recognize that both are partners in the open source world and that to ignore one over the other is destined to fail. I think Bruce article is about painting a realistic picture for companies who want to get involved. And the reality is that people tend to be worried about company influence quite often and they do expect a higher standard for patches coming from a (big) company. For individuals they are more forgiving, but if an IBM engineer does a little mistake it will produce a few (not necessarily open) snickers. regards, Lukas ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] todo list management
Hi, PostgreSQL 8.2 is out of the door. Unfortunately the plans for a more detailed todo list have not come into reality yet to assist in for the next 8.3 release. A couple people have replied to my earlier request to form a little team willing to work on this, but unfortunately people seem to have time constraints that prohibit them from working on this. I am still willing to spend time on being the person secretary of people, but I do not know enough about the internals of PostgreSQL to do this on my own, let alone start an initial list like I did for the PHP project. My goal is to for now cover the tricky long running todo's, document their progress, the people involved as well as any discussions and more importantly their conclusions. This should make it easier for other people to help on these todo's, or even take over if for some reason the original people do not have time to complete the todo themselves. This should also help people like Bruce, because they can get an idea about the progress without necessarily having to track down the people involved and it should also make the progress more transparent to end users. This is essentially what was started with the developers wiki already [1]. It seems the wiki is already seeing good use for the XML support and query progress indicator. Again, I am here and willing to help. I do not want to hassle this list with a lengthy thread, so hopefully the result will just be someone pushing me into the right directions. regards, Lukas [1] http://developer.postgresql.org/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] bug or feature, || -operator and NULLs
Martijn van Oosterhout wrote: By following your suggestion we would get the following oddity: SELECT NULL = '', NULL || 'fisk' = '' || 'fisk'; We would return NULL for the first and true for the second. Surely that's not logical? The problem is really that Oracle does not differntiate properly between '' and NULL. regards, Lukas ---(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] bug or feature, || -operator and NULLs
Andreas Joseph Krogh wrote: If aggregates ignore NULL one could argue that so shuld the ||-operator? I agree that this behaviour may seem pedantic, but changing this is only going to lead to a huge wtf? factor. The baviour for NULL in aggregates is pretty well documented and known. Even MySQL returns NULL in this case, and they are known todo all sorts of changes for better ease of use. If you want this behaviour you will have to explicitly handle it with COALESCE(). regards, Lukas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] bug or feature, || -operator and NULLs
Mario Weilguni wrote: Nice, but I still prefer nvl. Coalesce is hard to pronounce, and even harder to type. amen .. coalesce was invented by a sadistic twit (something which people have also called me .. so it goes). regards, Lukas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] bug or feature, || -operator and NULLs
Neil Conway wrote: I think a more sensible proposal could be made for some sort of optional compatibility mode, as has been discussed many times in the past: different NULL handling could theoretically be part of an Oracle SQL dialect. even more exciting in this context would be to add user controllable NULL sorting behaviour. afaik this is in sql:2003. regards, Lukas ---(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] 8.2 beta blockers
Lukas Kahwe Smith wrote: Peter Eisentraut wrote: Am Montag, 18. September 2006 09:20 schrieb Lukas Kahwe Smith: This just reminds me, are there plans to take into account multibyte server encodings inside the client quote function? Huh? Ah, I just checked the libpq docs and there seems to be a PQescapeStringConn. Not sure when this was added, I think PHP does not yet use it. I will investigate this and will make sure its used in favor of the deprecated old PQescapeString function. This will be fixed as of PHP 5.2.0 regards, Lukas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Developer's Wiki
Dave Page wrote: I have now moved the wiki installation to: http://developer.postgresql.org/ BTW: I am wondering if there is an RSS feed of the changes? On my wiki I have an RSS feed for every page, subwiki (aka area) and the entire wiki people can subscribe to: http://oss.backendmedia.com/rss.php?area=PHPTODOpage=HomePage http://oss.backendmedia.com/rss.php?area=PHPTODO http://oss.backendmedia.com/rss.php regards, Lukas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-www] Developer's Wiki
Martijn van Oosterhout wrote: On Mon, Sep 18, 2006 at 03:49:29PM +0200, Lukas Kahwe Smith wrote: I agree pretty much. However I disagree that a wiki is not useful to summarize discussion from the mailinglist. All that it needs is people that are humble and do not push their own agendas. If necessary they should discuss their summaries with members of both/all sides of a given discussion and with members of the core group. It would be helpful if people commented on the stuff already there and said if it's good, bad or otherwise. I just looked through the wiki. Generally I like whats there. It seems the approach taken is essentially that the unofficial todo items contain a current brain dump on the steps taken so far, the status and future work. So if any busy bees would want to join in and help, they would just keep close contact with the person that is working on the todo item. I think this is a great basis to make it easier for other people to join in and should be a solid basis for turning this into official todo items. The ICU todo item will maybe also become a good test bed for how to build up a document at the very early stages, where there will still be a lot of discussions on the mailinglists. Thinking a head (and maybe too far then we really need to at this point): So how will this work once they become official. I assume Bruce's todo list would then link to the wiki and the editing would become more conservative? Would the status get frozen? I assume that if the given functionality is expanded/changed in future releases then it would be done in the same document? Or would a new document be startet to detail the new development process that would simply optionally list previous documents? regards, Lukas ---(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] 8.2 beta blockers
Tom Lane wrote: I see the following items standing between us and putting out 8.2beta1: * Set client encoding based on OS environment - Peter E. I'm not sure whether Peter is intending to complete this item for 8.2 or not, but if it's to be done it ought to be done before we start beta. This just reminds me, are there plans to take into account multibyte server encodings inside the client quote function? regards, Lukas ---(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] 8.2 beta blockers
Peter Eisentraut wrote: Am Montag, 18. September 2006 09:20 schrieb Lukas Kahwe Smith: This just reminds me, are there plans to take into account multibyte server encodings inside the client quote function? Huh? Ah, I just checked the libpq docs and there seems to be a PQescapeStringConn. Not sure when this was added, I think PHP does not yet use it. I will investigate this and will make sure its used in favor of the deprecated old PQescapeString function. regards, Lukas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [pgsql-www] Developer's Wiki
Andrew Dunstan wrote: Being slightly more abstract, we are grappling with a couple of different kinds of objects here: discussions and decisions. The mailing list is a very good way of having a discussion, and a wiki is IMNSHO a poor substitute. Ditto, bulletin board, web forum, blog . The reason is simply that with a mailing list all you need is a subscription to get the info delivered to you in a medium everybody uses. It's push, not pull, and that's very appealing. Any other mechanism requires the user to seek the location of the discussion actively to some degree. Conversely, the very unstructured nature of the mailing list(s) makes them a poor medium for capturing decisions. That's why some of us have advocated use of a tracker to capture decisions about development directions, because the TODO list doesn't seem appropriate. But an open wiki would be a horrible substitute for the TODO list - it would turn it from a list that reflects at least some discussion and consensus into a mere wish list of no authority whatsoever. IOW, it is the exact opposite of the direction I believe we should be headed. I agree pretty much. However I disagree that a wiki is not useful to summarize discussion from the mailinglist. All that it needs is people that are humble and do not push their own agendas. If necessary they should discuss their summaries with members of both/all sides of a given discussion and with members of the core group. regards, Lukas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-www] Developer's Wiki
Andrew Dunstan wrote: Well, of course, the internet is renowned for its preponderance of people overburdened with humility and fairness. :-) I think if you ask the php development team the chances are high that they will agree that I have done exactly that for the PHP todo list. Seriously, what will be the point? It strikes me as likely to be a huge amount of wasted effort. If the wiki is updated by others then they will be using the wrong forum (should be on the mailing list). And I suspect nobody much will use it to look for anything. The point is that you no longer argue in circles, do not have to use the ever intimitating read the archives (which buys newcomers nothing since archives are essentially useless if you are trying to understand the contents of a lengthy discussion you did not partcipate in yourself) and give people some transparency. As for the TODO list, its items belong in a tracker, IMNSHO, as feature items (as opposed to bugs). So exactly what would go on a wiki? ISTM we are in danger of wanting to use technology because we like it, rather than because it is appropriate. The problem with a tracker is that again like complicated mailinglist threads, they rarely summarize things. Since most trackers are not threaded, they are less confusing to read up afterwards, but at the same time due to lack of threading they are less useful at discussing the issue. So imho a tracker is nice to make it very easy to query the status of a giving issue (fixed in branch xyz etc), a mailing list is great for discussions and a wiki is great for summarizing discussions. The wiki can be linked to inside the tracker/mailinglist. regards, Lukas PS: Did you intentionally only reply to me? ---(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] [pgsql-www] Developer's Wiki
Joshua D. Drake wrote: Gregory Stark wrote: Josh Berkus josh@agliodbs.com writes: I was actually hoping for more feedback on the content itself. I'm still not clear if it's supposed to be developers only - to the exclusion of users or developers only - but accessable to anyone. It should be readable by everyone, but editable only by authorized users. I think the lessons of wikipedia is precisely that you *don't* want to add such barriers. You want to let people add stuff pretty much freely. That encourages people to get involved and put up information. I don't agree, you should also look at the recent post and fork by one of wikipedia's co-founders. The developers wiki should only be edited by authorized users. Now, getting authorized should be easy as reasonably possible, but having a wholesale editing orgy on the wiki responsible for tracking postgresql developer information is not a good idea. I agree. Banning IPs is simply not feasible. I think a minor moderation step during the signup is little overhead and ensures we know who changed what etc. This is obviously not only important for blaming but also great for talking to people about a given page when it comes time to update it. I think however there should be a section that is free for all. It should be clearly labeled with parts are free for all and which are not. It should be easy to move pages from one section to the other and back. Essentially I would say the wiki should be open to anyone who signs up, however there should be pages that are only writeable to people inside a special group. I am not sure how the ACL works in the current wiki. SOme wikis allow you to define ACL's by page, some allow you to create subwikis with different ACLs etc. regards, Lukas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Mid cycle release?
Stefan Kaltenbrunner wrote: Interesting idea but we already have one of the fastest release cycles of all database systems and some people would like to see a larger cycle. I think the key complaint is about how painful the upgrade process is and if you still get fixes for previous releases if you are not willing to make the big jump. regards, Lukas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Getting a move on for 8.2 beta
Tom Lane wrote: AFAICS the bottom line here is that we need some intelligent filtering. In the short run I doubt that we can have that except through human gruntwork to filter the mail traffic and update a tracker database. Maybe after we see such a system in operation for awhile, we can start to automate some obvious bits. But if we start with the assumption that it's going to be mostly automated on day zero, I predict a resounding failure. I agree 100%. Lets start off with grunt workers doing their magic in parallel with whatever systems we currently have. They will one by one figure out what to automate, what cannot be automated, and maybe provide value that is promising enough for people to slightly modify their modus operanti for those aspects that cannot be automated. However there will probably always be a great deal of grunt work. Again Email's are great for discussions and I think its great to link up discussions with a bug or issue tracker id. However Email discussions also often go in circles, are side tracked by IRC discussions etc. So its really hard to figure out what decisions have been made if you look things up later on. So the task of the grunt workers is to make sure that there is a summary of the relevant information available, even if all they do is flag the important decision emails. regards, Lukas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Getting a move on for 8.2 beta
Andrew Dunstan wrote: I spent months on a working party on these and similar issues a few years back, in a commercial setting. One of the big issues is when you start tracking something. Bugs are a pretty simple case. Features are much harder to handle. Someone comes up with an idea. There is a lot of discussion. a consensus is arrived at to go forward. I think that's the point at which we start tracking, but it's a judgement call. What is we decide not to go ahead? Do we capture that in the tracker (with a resolution of rejected)? Exactly its a judgement call. The idea would be to try and pick up each of the proposals in the discussion, summarize them in the issue tracker or via a link to the wiki. This way people do not argue in circles all that much (hopefully) and there is something to vote on. More importantly there is something to point to if the topic ever comes up again and the previous discussion did not lead to a decision. The classic read the archives is just very suboptimal. regards, Lukas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Getting a move on for 8.2 beta
Andrew Dunstan wrote: It would make the process more transparent, which is something several people have expressed a desire for. Yes, the processes seems to work by having two of the most important people waste time on getting information anyone else could collect, or that the developer himself could quickly provide and keep up to date. Furthermore the process expects these two people to know who to ask, what to look for etc. Wouldn't it be great if someone could just decide: hey I know postgres, I have some unexpected spare time, I want to do some code reviewing on patch x, y and z If this all works through some issue tracker, a wiki or a combination of both, the end result is transparency, the opportunity to take load off from people that have important other things to do and a chance at getting unexpected help. For example I have no expertise in coding on Postgres, but I think I would be able to collect information from this mailinglist (like specs, url's etc.) and put them in some issue tracker or wiki. I have done exactly the same for PHP [1] (though there are rarely specs thrown around in PHP, so my PHP todo list is not much more than a simple bullet list of todo's with a name and occasional URL's to additional information). regards, Lukas [1] http://oss.backendmedia.com/PHPTODO/ ---(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] Getting a move on for 8.2 beta
Lukas Kahwe Smith wrote: For example I have no expertise in coding on Postgres, but I think I would be able to collect information from this mailinglist (like specs, url's etc.) and put them in some issue tracker or wiki. I have done exactly the same for PHP [1] (though there are rarely specs thrown around in PHP, so my PHP todo list is not much more than a simple bullet list of todo's with a name and occasional URL's to additional information). Actually I should add that I went ahead and created the PHP todo list on my own, without any official blessing and one by one internals developer have joined. Now its actively used in the entire release process. This is probably the best approach to go about doing this for PostgreSQL as well. That way there is no additional work, and instead it can show if it actually helps people. And if it does more people will start to contribute to it. If not then someone who did not contribute to the code anyways wasted a bit of time to get to know the PostgreSQL todo items really well. ;) regards, Lukas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Getting a move on for 8.2 beta
Robert Treat wrote: No offense, a whole lot of this thread seems to be positioned that way, but the real problem seems to be we do not have enough patch reviewers. ISTM the questions we should be asking are who can actually help out with patch review and then ask those people why they haven't done it. If folks like Peter, Andrew, Magnus, Simon, Joe, and Niel all say that they are not reviewing patches because they can't find the patches that need review, they can't figure out who is reviewing what, or they don't think anyone is paying attention when they do review something, then I think we have a serious problem and we certainly need to change processes. What I think you'll find is that they are all just busy working on other things, which in that case I think we need to figure out how to motivate them to focus on the patch queue rather than other items.IMHO I think that if all the patches are listed with all relevant context information on a webpage, then people can more easily jump in when they unexpectedly have time (or prefer to procrastinate some other real world thing they should rather work on). Right now if you have a few hours to spare you do not have all the information readily available. Even worse by inquiring for the information you might feel you are commiting more than you really wanted to. This kind of information needs to be right there without any person having to actively provide it upon inquiry. regards, Lukas ---(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] Getting a move on for 8.2 beta
Peter Eisentraut wrote: Martijn van Oosterhout wrote: I remember something about setting up a wiki for a todo list and pie in the sky list. I thought it had promise, but until the wiki is there we won't know... I think the wiki is the prerequisite for many ideas about alternative tracking and documentation mechanisms. I just wonder what the hold up is on it. We have a wiki already: http://wiki.postgresql.org/ It could be a bit faster, but its there. I even already started on a little documentation effort: http://wiki.postgresql.org/index.php/pgwiki:Variations regards, Lukas ---(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] Postgres tracking - the pgtrack project
Greg Sabino Mullane wrote: Yes, maintaining it will be a royal pain in the butt. But my theory has been if you build it, they will come. It will require a lot of human interaction, as automation only takes you so far, especially when trying to parse mailing list messages. But if we eventually get a decent-size group of people who each put in a little work on it, it should be quite possible to keep it up to date. (Also, this would be a great way for people to help the project who don't have the time and/or skills to do coding). I think we should start with the wiki and then add in whatever we notice can be automated. This way we may not initially be able to cover all the bases, but it will mean that whatever we do automate actually matches real world requirements. The idea is to allow everything to happen as it already does, e.g. no extra burdens for Tom, no extra processes anywhere. However, all the existing information is gathered into one centralized and searchable place. The primary sources will include the code, the docs, and the mailing lists. Especially the mailing lists. Yeah, let the ones work on this that do not do any of the pgsql coding. regards, Lukas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Getting a move on for 8.2 beta
Joshua D. Drake wrote: That wiki is wrong. :) It was set up wrong and configured wrong. It was supposed to be for developers only. There is also another wiki that is a trac based that was set up at dave pages request (for slaves_to_www). Setup something better, until then we can start using it to generate content. I even already started on a little documentation effort: http://wiki.postgresql.org/index.php/pgwiki:Variations And note it has already been mentioned that, that wiki was the wrong place to put it. Not that I am slamming your efforts, I think it was really good that you did the docs :). They are just in the wrong place. No problem. Its easy to move content, its much harder to generate it. regards, Lukas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Getting a move on for 8.2 beta
Bruce Momjian wrote: Lukas Kahwe Smith wrote: Robert Treat wrote: No offense, a whole lot of this thread seems to be positioned that way, but the real problem seems to be we do not have enough patch reviewers. ISTM the questions we should be asking are who can actually help out with patch review and then ask those people why they haven't done it. If folks like Peter, Andrew, Magnus, Simon, Joe, and Niel all say that they are not reviewing patches because they can't find the patches that need review, they can't figure out who is reviewing what, or they don't think anyone is paying attention when they do review something, then I think we have a serious problem and we certainly need to change processes. What I think you'll find is that they are all just busy working on other things, which in that case I think we need to figure out how to motivate them to focus on the patch queue rather than other items.IMHO I think that if all the patches are listed with all relevant context information on a webpage, then people can more easily jump in when they unexpectedly have time (or prefer to procrastinate some other real world thing they should rather work on). Right now if you have a few hours to spare you do not have all the information readily available. Even worse by inquiring for the information you might feel you are commiting more than you really wanted to. This kind of information needs to be right there without any person having to actively provide it upon inquiry. OK, how does that happen without a lot of work, or moving all discussion on to a web-based system? No discussion takes place on the lists and IRC and busy bees make sure that the progress/decisions etc get updated on the static wiki. Wiki's suck at discussions, but they are great to store the decisions made so that anyone can get himself upto speed and things do not get lost over time. It seems that you have been the only busy bee so far, and we definitely need more for this to work. regards, Lukas ---(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] Getting a move on for 8.2 beta
Bruce Momjian wrote: It seems that you have been the only busy bee so far, and we definitely need more for this to work. Yea, I was afraid that was the answer. :-( But we have a few volunteers, like me for example. Now don't say I was afraid that was the answer again or I might feel insulted :) regards, Lukas ---(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] Prepared statements considered harmful
Martijn van Oosterhout wrote: On Thu, Aug 31, 2006 at 07:04:07PM -0400, Gregory Stark wrote: The server has to prepare the query sometime. The v3 protocol just gives you control over when that happens, but it doesn't force you to do it at any particular time. Not really. All named prepares are planned straight away, all unnamed ones are planned at bind time. Therefore you cannot have more than one parsed-but-not-planned prepared query at a time. In a connection pool scenario there's no way to share such plans since you can't tell which query has been prepared. That's not forcing, but it's an asymmetry we could do with out. AFAIK since Oracle 9i planning is always deferred until the first execution. This way they hope to get a better plan, which would obviously not be possible if the selectivity varies greatly. So are the plans generated without taking any bound values into account more stable in performance (albeit at times slower than what would have been produced if the value would have been known)? Either way mixing the question of when to prepare the plan with the prepared statement being named or unnamed seems unexpected. regards, Lukas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Prepared statements considered harmful
Peter Eisentraut wrote: Am Donnerstag, 31. August 2006 14:52 schrieb Csaba Nagy: So for the like query case you could save 2 plans, one for the indexable case, one for the not indexable case. Then at runtime you choose the proper one based on the pattern value. OK, why don't you work out an example. Let's look at this query: SELECT * FROM t1 WHERE a LIKE $1; What two plans would you prepare? Well I guess for the case that none of the expected plans fit you can always fallback to generating a new plan on the fly. Anyways it would of course be cool if pgsql could set an invalid flag if it detects that a certain plan performed badly (maybe even automatically cause a fresh table analysis) or some DDL/DML was executed that likely invalidated the plan. I am not sure if there is any philosphie that pgsql tries to adhere to. Does it want to leave the job of tuning to the DBA or does it want to do things automatically (which always means that in some situations it will do the wrong thing). tweak planner vs. planner hints manually analyze vs. automatically analyze manual vaccum vs autovaccum Hmm actually its probably not a black and white thing and the ultimate goal would be to offer both with maybe some installer checkbox to default everything to DBA-less automode. Anyways I never liked the idea of planner hints. I think it makes much more sense to give people direct access to plans in that case. Meaning they can partially hardcode (parameterized) plans they want. I have mentioned before that Sybase seems to have such a feature (you can dump plans, tweak them and remove pieces that should be done on the fly and associate them with stored procedures - not sure if you also do that for prepared statements). regards, Lukas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Prepared statements considered harmful
Martijn van Oosterhout wrote: On Thu, Aug 31, 2006 at 11:27:18AM -0400, Tom Lane wrote: I'd wish that we reconsider when and how prepared statements are used. The JDBC interface and PL/pgSQL are frequently noticed perpetrators, but the problem is really all over the place. AFAIK those are the only two places where preparation is the default ... what else were you thinking of? Perl DBI (DBD::Pg) defaults to prepared plans when connecting to a version 8.0 or higher server. Or at least, that's the way I read the documentation. AFAIK this is also the case for PHP PDO extension, which is bundled since PHP 5.1. regards, Lukas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Prepared statements considered harmful
Lukas Kahwe Smith wrote: Martijn van Oosterhout wrote: On Thu, Aug 31, 2006 at 11:27:18AM -0400, Tom Lane wrote: I'd wish that we reconsider when and how prepared statements are used. The JDBC interface and PL/pgSQL are frequently noticed perpetrators, but the problem is really all over the place. AFAIK those are the only two places where preparation is the default ... what else were you thinking of? Perl DBI (DBD::Pg) defaults to prepared plans when connecting to a version 8.0 or higher server. Or at least, that's the way I read the documentation. AFAIK this is also the case for PHP PDO extension, which is bundled since PHP 5.1. BTW: PDO has gotten a switch to force client side placeholder replacement in favor of using server side prepared statements due to the fact that prepared statements side-step the MySQL query cache. http://netevil.org/node.php?uuid=444a6017-0548-2459-2943-44a601714d58 BTW: I am not posting this to solicit MySQL bashing. The main reason why PDO pushes prepared statements is the fact that they offer good protection against SQL injection. However obviously in shared nothing architectures like PHP, which does not yet have any sort of connection/statement-pooling solution, the danger of prepared statements becoming stale over time is small. However the problem of running the same statements with two different parameters that require different plans is still quite real. regards, Lukas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] news server does not respond
Markus Schiltknecht wrote: Marc G. Fournier wrote: Fixed, sorry for delay ... Good, thank you. But I've already switched back to IMAP, with subfolders and automatic filtering. Has the advantage of being available from any IMAP capable client _and_ saving the flags. Looks like the news server is not used that much, if I was the only one complaining... Uhm, I am using it as well and I noticed a few others complaining as well on IRC. All the better that it is back in action :) regards, Lukas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Reinoud van Leeuwen wrote: On Thu, Aug 10, 2006 at 09:02:36PM -0700, Joshua D. Drake wrote: I think it is a combination of the two. A wiki could be used to discuss ideas for todos, it could be used to describe TODOs in actual detail, it could used (in conjunction with Trac) to be able to document dependecies for todos... etc. A wiki for *discussion*? I thought email was for that. A wiki is nice to work toghether on a document (in some circumstances). I dont he meant that. A wiki is a good place to summarize an email discussion, not to actually hold a discussion on the wiki (I have seen it done though .. and its not pretty). regards, Lukas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
Bruce Momjian wrote: I am saying other people can try a new system, but I don't have time to try something different when no evidence has been given that it is better (just different). Ok, not sure if I am in a position to call shots like I am about to, but here it goes: Could everybody who is willing to invest time setting up an alternative contact me so that we can maybe get together in IRC to talk things through and come up with a solid game plan? Maybe with such a plan we can also get Bruce to atleast give us infrequent, even very raw, brain dumps so that we do not face developers with all too much redundant information seeking. regards, Lukas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] monolithic distro
Marc G. Fournier wrote: But, that isn't our role ... that should be the role of whomever takes on the role of 'maintainer' for such a monolithic distribution ... its no more our role to decide that pl/Java is better or worse then pl/J ... our role is to provide that core for everyone else to build around ... People like CommandPrompt, Bizgres, EnterpriseDB, Pervasive ... they have the funding to *create* and maintain that, to make sure all the parts they distribute are working properly ... The resources are there, if someone (you?) wants to do this as a FOSS project, but I fear that amount of work (both time and energy) required to make the 'include all, for all' distribution is much much greater then the returns will be ... the more you add in, the more you have to co-ordinate releases with the external projects, and pull/push old/new stuff in as it becomes 'stale', etc ... Yeah, but if PostgreSQL decides to endorse one monolithic distro in the way I described it could give that project hopefully the necessary lift. And the ultimate goal is obviously that some of those newbies coming by way of the monolithic distro turn into people that bring ressources to the PostgreSQL platform/ecosystem. regards, Lukas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] monolithic distro
Marc G. Fournier wrote: Yeah, but if PostgreSQL decides to endorse one monolithic distro in the way I described it could give that project hopefully the necessary lift. And the ultimate goal is obviously that some of those newbies coming by way of the monolithic distro turn into people that bring ressources to the PostgreSQL platform/ecosystem. Should Linus endorse (or does he?) one distro of Linux, or should they not live on their own merits? Well right now PostgreSQL endorses the core distro. I guess similar to the Linux Kernel by Linus. However the difference is that Linux has a huge market share, whereas PostgreSQL is continuously complaing that MySQL is inferior yet way more popular. Maybe MySQL's popularity is not even PostgreSQL's goal, but I am sure a bit more would be welcome. So yes I think right now it would make sense to endorse a monolithic distribution. regards, Lukas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Martijn van Oosterhout wrote: On Sat, May 20, 2006 at 10:36:25AM +0200, Lukas Smith wrote: The improvements to the installer are great, but there simply needs to be a packaged solution that adds more of the things people are very likely to use. From my understanding Bizgres goes in that direction? I just think that whatever highly packaged solution PostgreSQL picks, this should be the download that is pushed at conferences, in articles and books. People with a clue will still know where they can get the clean base. There is a fantastic packaged solution already: apt-get install postgresql-8.1 postgresql-contrib-8.1 Voila! Tsearch installed at your fingertips. What else were you expecting? I expect this to be one package and I expect this to be what is pushed as the default package on all platforms. If someone just sat in an pgsql talk (or even a talk that mentions pgsql), has read an article, picked up a book .. this is what he should be downloading and installing. I do think that the name PostgreSQL has a fair amount of mindshare, but I do not think that this package needs to be called PostgreSQL necessarily. The problem with calling it PostgreSQL is that this would mean moving things into the core distribution which do not belong there. But expecting the unwashed masses to understand that they need to install contrib ontop of PostgreSQL is not a good idea. If PostgreSQL pushes FooSQL as its packaged solution at all opportunities I am sure it would quickly get into the heads of people and if done in a concerted effort along with the corporate sponsors it could provide for a huge marketing opportunity and a slew of articles from the press. But that is a topic for another list. regards, Lukas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
David Fetter wrote: On Thu, May 18, 2006 at 09:58:21PM +0200, Lukas Smith wrote: In what way is this outdated? Please provide a specific example. see below .. You have to understand that MySQL evolves just like PostgreSQL does. If it were true, I would have to understand it, but the way MySQL evolves is not even remotely like the way PostgreSQL does. Here are a few concrete differences: Ok, I was not trying to imply that MySQL evolves in the same way .. only that it also evolves. You've made some sweeping allegations here and no specifics. sweeping allegations? http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html SET [GLOBAL|SESSION] sql_mode='ALLOW_INVALID_DATES' That being said the solution is still lacking. I even filed a bug report over this: http://bugs.mysql.com/bug.php?id=17998 So I guess you can continue your commentary. Anyways, it was not my intention to educate PostgreSQL developers about MySQL, only that it would be wise not to make general comments about MySQL if you do not follow its development. regards, Lukas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Automatic function replanning
Bruce Momjian wrote: Right, if the cardinality changes, you realize this before execution and optimize/save the plan again. A further optimization would be to save _multiple_ plans for a single prepared plan based on constants and choose one of the other, but that is beyond where we are willing to consider at this stage, I think. ok .. so you store the cardinality that was used when generating the original plan. on the next execution you look up the cardinality again and compare it, if its off too much, you replan. however this could in extreme cases mean that you replan on every execution and thereby killing off the entire advantage of storing the plan. but thats the absolute worse case scenario. regards, Lukas PS: bruce original email was only send to me directly .. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
