Re: [HACKERS] What can we learn from MySQL?
Bruce Momjian wrote: My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. MySQL was my first introduction to SQL databases (I had dabbled with Clipper and Foxpro years earlier, but only for a couple of months and had forgotten most of it by then). So practically all I knew about SQL and RDBMS I got from the MySQL manual. IIRC, MySQL has a chapter for beginners, on how to create your first database and tables, how to insert a record, etc. I see that the Pg manual already has that. Good. The problem is that, since MySQL was my only SQL database I knew for a long time, I didn't know that an RDBMS can be [much] more than what MySQL was/is. I could only do simple SELECTs (no JOINs, let alone subselect since MySQL doesn't support it) but found it sufficient, since I did most of the hard work from Perl/PHP (for example, doing an adjacency tree query by several SELECTs and combining the results myself from the client side). I didn't know squat about stored procedures or triggers or check constraints. I had no idea what a foreign key is -- and when MySQL manual says it's not necessary, slow, and evil, I believed it. I never bothered checking out other databases until I started reading more about transactions, reliability, Date/Codd, and other more theoretical stuffs. Only then I started trying out Interbase, Firebird, SAPDB, DB2, Oracle, and later Pg. So in my opinion, as long as the general awareness about RDBMS (on what tasks/responsibilities it should do, what features it generally has to have, etc) is low, people will be looking at MySQL as good enough and will not be motivated to look around for something better. As a comparison, I'm always amazed by people who use Windows 95/98/Me. They find it normal/good enough that the system crashes every now and then, has to be rebooted every few hours (or every time they install something). They don't know of anything better. So perhaps the direction of advocacy should be towards increasing that awareness? -- dave ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [pgsql-advocacy] What can we learn from MySQL?
My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. Questions I have are: I have already told Bruce at length about the single most common complaint in the phpPgAdmin lists and in the IRC channel: the inability to change column types. I think we should listen to the punters on that one. Also, how about a new section in the manual: PostgreSQL for MySQL users and PostgreSQL for Oracle users? Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] License question
Shachar Shemesh kirjutas N, 22.04.2004 kell 19:49: The BSD license, in contrast to PostgreSQL's, does NOT require me to copy license related texts around, only the copyrights themselves. It does pose certain restrictions on what I am allowed to do with the copyrights, but any modern free software license (GPL included) require that you keep the copyright notices around * Copyrights by themselves do not give others any rights to use copyrighted material, licenses do. Copyrights reserve all rights by default. * On can license only that for what he owns IP (copyright, patent, ...). ergo, to allow other to use the code, there must be a license from the copyright holder. If you just keep the copyrights and not the license (either as full text or reference) you either effectively deny others the right to use the code as provided by you or claim ownership of code you do not really own. Now, I'm not trying to heal the world. It's enough to me that the current copyright owners give me permissions to use the code under the LGPL license. I am saying that calling the PostgreSQL license BSD license is misleading. IIRC BSD stands for Berkeley Standard Distribution, and as PostgreSQL was originally released as free software from Berkeley under this license it would be weird indeed to call it anything else. -- Hannu ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] License question
Shachar Shemesh kirjutas R, 23.04.2004 kell 07:53: Tom Lane wrote: Jeff Davis [EMAIL PROTECTED] writes: Also, can you license code at all if it isn't yours? I would assume you would have to make changes and license the changes you made, and distribute it along with the postgresql-licensed code. You can't relicense code you don't own Sure you can. You can only add additional restrictions for the combined code, not lift original ones. That is unless the original licence allows it :) You are free to relicence public domain code though, but I guess that by doing so you kind of take ownership of your release verion. IANAL --- Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] License question
IIRC BSD stands for Berkeley Standard Distribution, and as PostgreSQL was originally released as free software from Berkeley under this license it would be weird indeed to call it anything else. FWIW, 'Berkeley Software Distribution'. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] What can we learn from MySQL?
Bruce Momjian wrote: Here is a blog about a recent MySQL conference with title, Why MySQL Grew So Fast: http://www.oreillynet.com/pub/wlg/4715 and a a Slashdot discussion about it: http://developers.slashdot.org/article.pl?sid=04/04/20/2229212mode=nestedtid=137tid=185tid=187tid=198 My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. Questions I have are: o Are we marketing ourselves properly? o Are we focused enough on ease-of-use issues? o How do we position ourselves against a database that some say is good enough (MySQL), and another one that some say is too much (Oracle) o Are our priorities too technically driven? Do we care enough about interoperability? When I ask about non-standard complience of Pg (turning unquoted identifiers to lowercase instead of uppercase, violating the SQL standard, and requring an expensive rewrite of clients), and I get the answer uppercase is ugly, I think something is wrong. To be fair, I got a fair amount of legitimate problems with MIGRATING to standard compliency. I find these issues legitimate, though solveable. Getting a we prefer lowercase to the standard, however, means to me that even if I write a patch to start migration, I'm not likely to get it in. Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] What can we learn from MySQL?
My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. Questions I have are: o Are we focused enough on ease-of-use issues? There are two issues here : ease-of-use for admin and basic users. I recognize my focus on the later as someone using pg as a teaching tool. Having a correct SQL implementation, referential integrity and transactions is an important issue when explaining DB concepts. That's why I could not have used mysql. Having some help/hint/advices/caveat provided for basic users would help. But some of the change I submitted require a lot of changes, especially in the parser, hence are rejected. I also submit patch to try to fix some surprises (there is != but not ==, non-user tables are in stat_.._user_tables viewa...) I had while using pg. My agenda is quite hard to get thru the hacker/patch lists. Maybe because the patches I sent are not really good enough, but also because it is not a real focus of postgres developers. On for former point, admin ease-of-use, A little story a few month ago. I succeeded in advising production people here to switch some applications from a mysql database, which was working perfectly, to a postgres database. A few weeks later, the performances were desastrous. 30 seconds to get an answer to a simple select on a 1500 entries tables. After investigation, the problems were: - no vacuum, although there were daily DELETE FROM tables; to empty all the data and reload from another source. - no analyze, because the admin did not know about it. - very small shared_buffers setting (16 the minimum thanks to FreeBSD default installation...). With mysql, you don't need to vacuum analyze, and I think the memory management maybe more or less automatic. I think that the default configuration should have some automagic features so that reasonnable values are chosen depending on the available resources, which would allow basic users not to care about it. memory_management = auto/manual... You also need to have a basic standalone binary port to windows. I wish I could allow simply my students to use pg on their home computers. Well, it does not work that simply, you need cygwin at the time, and I haven't seen the windows binary available for download from the pg download page. o How do we position ourselves against a database that some say is good enough (MySQL), and another one that some say is too much (Oracle) free and serious. o Are our priorities too technically driven? Not bad if other agendas can also get through. -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: 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] What can we learn from MySQL?
On Fri, Apr 23, 2004 at 01:05:21PM +0700, David Garamond wrote: So in my opinion, as long as the general awareness about RDBMS (on what tasks/responsibilities it should do, what features it generally has to have, etc) is low, people will be looking at MySQL as good enough and will not be motivated to look around for something better. As a comparison, I'm always amazed by people who use Windows 95/98/Me. They find it normal/good enough that the system crashes every now and then, has to be rebooted every few hours (or every time they install something). They don't know of anything better. Agree. People don't know that an RDBMS can be more better. A lot of users think speed is the most important thing. And they check the performance of SQL server by time mysql -e SELECT... but they don't know something about concurrency or locking. BTW, is the current MySQL target (replication, transactions, ..etc) what typical MySQL users expect? I think they will lost users who love classic, fast and simple MySQL. The trade with advanced SQL servers is pretty full. I don't understand why MySQL developers want to leave their current possition and want to fight with PostgreSQL, Oracle, DB2 .. etc. Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] What can we learn from MySQL?
On Fri, 23 Apr 2004, Shachar Shemesh wrote: When I ask about non-standard complience of Pg (turning unquoted identifiers to lowercase instead of uppercase, violating the SQL standard, and requring an expensive rewrite of clients), and I get the answer uppercase is ugly, I think something is wrong. I would love if someone fixed pg so that one can get the standard behaviour. It would however have to be a setting that can be changed so we are still backward compatible. that even if I write a patch to start migration, I'm not likely to get it in. Just changing to uppercase would break old code so such a patch should not just be commited. But would people stop a patch that is backward compatible (in the worst case a setting during initdb)? I'm not so sure they will. -- /Dennis Björklund ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] What can we learn from MySQL?
Karel Zak wrote: On Fri, Apr 23, 2004 at 01:05:21PM +0700, David Garamond wrote: So in my opinion, as long as the general awareness about RDBMS (on what tasks/responsibilities it should do, what features it generally has to have, etc) is low, people will be looking at MySQL as good enough and will not be motivated to look around for something better. As a comparison, I'm always amazed by people who use Windows 95/98/Me. They find it normal/good enough that the system crashes every now and then, has to be rebooted every few hours (or every time they install something). They don't know of anything better. Agree. People don't know that an RDBMS can be more better. A lot of users think speed is the most important thing. And they check the performance of SQL server by time mysql -e SELECT... but they don't know something about concurrency or locking. Even worse: They benchmark SELECT 1+1 one million times. The performance of SELECT 1+1 has NOTHING to do with the REAL performance of a database. Has anybody seen the benchmarks on MySQL??? They have benchmarked CREATE TABLE and so forth. This is the most useless thing I have ever seen. It is so annoying _ I had to post it ;). Regards, Hans BTW, is the current MySQL target (replication, transactions, ..etc) what typical MySQL users expect? I think they will lost users who love classic, fast and simple MySQL. The trade with advanced SQL servers is pretty full. I don't understand why MySQL developers want to leave their current possition and want to fight with PostgreSQL, Oracle, DB2 .. etc. Karel -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/2952/30706 or +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There's more than one issue. CPAN makes it easy for end users to find and install little projects. One thing I would like to see is a more direct link to the drivers (e.g. DBD::Pg, JDBC) from the download page. I don't think they need to live in contrib, but having them on the download page right next to the latest PG server files would do wonders. All the maintainers of external projects would have to do is make sure that the link points to where they want it to. For example. look at how MySQL handles the DBD::mysql client (which is hosted at CPAN, not mysql). http://dev.mysql.com/downloads/index.html The download page above has the server links, a few others, and then: DBI -- for connecting to MySQL from Perl Clicking on DBI gives you a small, clean page that explains what DBI is and gives links to DBI and DBD::mysql, both hosted on cpan.org. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200404230734 -BEGIN PGP SIGNATURE- iD8DBQFAiQBDvJuQZxSWSsgRAqn5AJ4pEllgPCiTVfAcrK21r62RgD1tdACg4IHz hAb4LBiqlIMbBF2bsXdZDDI= =xPFb -END PGP SIGNATURE- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] What can we learn from MySQL?
Dennis Bjorklund [EMAIL PROTECTED] writes: On Fri, 23 Apr 2004, Shachar Shemesh wrote: When I ask about non-standard complience of Pg (turning unquoted identifiers to lowercase instead of uppercase, violating the SQL standard, and requring an expensive rewrite of clients), and I get the answer uppercase is ugly, I think something is wrong. I would love if someone fixed pg so that one can get the standard behaviour. It would however have to be a setting that can be changed so we are still backward compatible. Yes. There have been repeated discussions about how to do this, but no one's come up with a solution that seems workable. See the archives if you care. For the foreseeable future, backwards compatibility is going to trump standards compliance on this point. That doesn't mean we don't care about compliance; it does mean that it is not the *only* goal. I find it a bit odd to be debating this point in this thread, seeing that one of the big lessons I draw from MySQL is standards compliance does not matter... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Tom Lane wrote: The specific details aren't especially relevant to this thread, though. What is relevant is that we agree to a commitment that we will make it easy to build modules outside the current Postgres build environment, and that we will have an ongoing commitment to make sure that that keeps working. Agreed. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
The specific details aren't especially relevant to this thread, though. What is relevant is that we agree to a commitment that we will make it easy to build modules outside the current Postgres build environment, and that we will have an ongoing commitment to make sure that that keeps working. Maybe you should try to mimic apache apxs script behavior? It allows to compile, install, configure new modules into apache. pg_config is not convincing at the time: shell pg_config --includedir-server /usr/local/pg750a/include/postgresql/server shell ls /usr/local/pg750a/include/postgresql/server ls: /usr/local/pg750a/include/postgresql/server: No such file or directory Too bad, server headers are not installed by default:-( -- Fabien. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-advocacy] What can we learn from MySQL?
Christopher Kings-Lynne wrote: My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. Questions I have are: I have already told Bruce at length about the single most common complaint in the phpPgAdmin lists and in the IRC channel: the inability to change column types. I think we should listen to the punters on that one. Yea, I will push that for 7.5. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-advocacy] What can we learn from MySQL?
Am Freitag, 23. April 2004 06:09 schrieb Bruce Momjian: o Are we marketing ourselves properly? o Are we focused enough on ease-of-use issues? o How do we position ourselves against a database that some say is good enough (MySQL), and another one that some say is too much (Oracle) o Are our priorities too technically driven? Success is not measured by absolute number of installations. You can measure success by having enough users so that the project can continue, enough users so you can make a living, more satisfied users than unsatisfied ones, more heavy-duty installations than personal database-driven websites, and by having a product that you feel good about. The only way to position ourselves is as the relational database with the best price/performance ration (price = TOC, performance = features + speed). And the only way to achieve any of these goals is by focussing on technology and ease of use. For the crowd out there, PostgreSQL is an exciting and growing topic. That's more important than the installation count. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] What can we learn from MySQL?
There are two issues here : ease-of-use for admin and basic users. On for former point, admin ease-of-use, A little story a few month ago. I succeeded in advising production people here to switch some applications from a mysql database, which was working perfectly, to a postgres database. A few weeks later, the performances were desastrous. 30 seconds to get an answer to a simple select on a 1500 entries tables. After investigation, the problems were: - no vacuum, although there were daily DELETE FROM tables; to empty all the data and reload from another source. - no analyze, because the admin did not know about it. My goal is to have pg_autovacuum integrated into the backend for 7.5. I don't know if it will default to being turned on or off, I'm sure that will be a discussion, but if it is defaulted to on, then this whole problem of having to train newbies about vacuum should just go away. Matthew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] What can we learn from MySQL?
Dear Matthew, My goal is to have pg_autovacuum integrated into the backend for 7.5. I know about that, and that would be a good thing. I don't know if it will default to being turned on or off, I'm sure that will be a discussion, but if it is defaulted to on, then this whole problem of having to train newbies about vacuum should just go away. Yes. I really thing that it should be on by default, because those who will need it more than others are those who will not know about tuning configuration parameters. As I understand the requirements from pg_autovacuum, it means that some statistics will have to be on by default as well. Good luck;-) -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: 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] What can we learn from MySQL?
Bruce Momjian wrote: My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. MySQL became popular at my university when the students discovered they could install it on their personal computers. Just the exposure for personal development and trial is enough to win a following. Win32 installations are a big deal. With win32 machines outnumbering *nix operating systems by more than 10 to 1 (more on personal computers), the unix only restriction reduced the number of possible people testing and developing with it by at least that amount. Most developers I know work primarily on Windows workstations and asking for a machine to run Postgresql on unix is just not practical. With the win32 port, they can run it on their computers and at least test or evaluate their projects. I and a number of my friends are exceptionally please at the progress of the win32 port. Thank you! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
On Thu, 2004-04-22 at 23:05, Robert Treat wrote: On Thursday 22 April 2004 13:55, Barry Lind wrote: I think the solution lies in improving www.postgresql.org. At the end of the day it doesn't matter where source code lives, what matters is can people find what they are expecting. Given we know what people are looking for, that should be front and center on the web site and the ftp sites. But of course that solution always stalls out when it comes down to picking which projects get the special treatment of direct links from the main website and which ones stay out of the spotlight. With JDBC you might make Most end users don't care if they can choose between 20 administration interfaces. They want to know which one works the best and just use that. Guidelines: 1. Must be fully functional with new release of PostgreSQL on day of PostgreSQL release -- all features. (Admin programs should know how to create and manage all objects). 2. Must function across a majority of platforms that PostgreSQL supports. 3. Must be available for free. Something we could *and will* distribute via CD or could be installed by default. Likewise, source code must be available to ensure it does not become discontinued. 4. Must be high quality -- equivalent to that of PostgreSQL itself. 5. It should be something that a company selling PostgreSQL support would be willing to take on. 6. Must have demonstrated the above prior to inclusion on the download page (gone through a full cycle). 7. They must be willing to change the name to something generic. I.e. PostgreSQL Administration Interface or PostgreSQL Java Connector. In other-words, they need to be willing to be a part of the larger PostgreSQL community. If someone thinks that the JDBC drivers are broken, the JDBC folks should be open to debate on how to solve the issues or otherwise argue that there are no problems. Same as how PostgreSQL itself works. I really don't see this as being any different than deciding which buffer strategy or website style to use. One is better in some way so it becomes a part of the system. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] What can we learn from MySQL?
My goal is to have pg_autovacuum integrated into the backend for 7.5. I know about that, and that would be a good thing. I hope so! I don't know if it will default to being turned on or off, I'm sure that will be a discussion, but if it is defaulted to on, then this whole problem of having to train newbies about vacuum should just go away. Yes. I really thing that it should be on by default, because those who will need it more than others are those who will not know about tuning configuration parameters. As I understand the requirements from pg_autovacuum, it means that some statistics will have to be on by default as well. I think it's premature to have this conversation. I need to get something done / working before we dicuss optimal configuration. That said, I also agree that if it's good enough, it should be on by default. Good luck;-) Thanks, I'll need it Matthew ps: I'm hoping to have time to work on this starting in May. I haven't really done any development on pg_autovacuum beyond bug fixing what is already in CVS, so If someone out there wants to work on it, don't wait for me, I won't be offended :-) I just want to see it up and running. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, 2004-04-23 at 05:22, Dennis Bjorklund wrote: On Fri, 23 Apr 2004, Shachar Shemesh wrote: When I ask about non-standard complience of Pg (turning unquoted identifiers to lowercase instead of uppercase, violating the SQL standard, and requring an expensive rewrite of clients), and I get the answer uppercase is ugly, I think something is wrong. I would love if someone fixed pg so that one can get the standard behaviour. It would however have to be a setting that can be changed so we are still backward compatible. that even if I write a patch to start migration, I'm not likely to get it in. Just changing to uppercase would break old code so such a patch should not just be commited. But would people stop a patch that is backward compatible (in the worst case a setting during initdb)? I'm not so sure they will. I know this to be true, but don't fully understand it... if our default behavior is to fold lower, and we change it to just fold upper... then in theory this shouldn't break anything since what used to be folder lower will now simply be folder upper. the only people who will have a problem are those who quote on one end but not the other, which is bad practice anyways... so i would say if your serious about it, make the patch as GUC case_folding for upper or lower and get a taste for what breaks inside the db. Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL ---(end of broadcast)--- TIP 3: 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] What can we learn from MySQL?
Matthew T. O'Connor wrote: I think it's premature to have this conversation. I need to get something done / working before we dicuss optimal configuration. That said, I also agree that if it's good enough, it should be on by default. Good luck;-) Thanks, I'll need it Matthew ps: I'm hoping to have time to work on this starting in May. I haven't really done any development on pg_autovacuum beyond bug fixing what is already in CVS, so If someone out there wants to work on it, don't wait for me, I won't be offended :-) I just want to see it up and running. I am around for assistance. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] What can we learn from MySQL?
Does the current implementation of pg_autovacuum have a way of setting windows where it is allowed to vacuum? Many large 24/7 will only allow vacuumming at certain times of the day. Dave On Fri, 2004-04-23 at 08:58, Matthew T. O'Connor wrote: There are two issues here : ease-of-use for admin and basic users. On for former point, admin ease-of-use, A little story a few month ago. I succeeded in advising production people here to switch some applications from a mysql database, which was working perfectly, to a postgres database. A few weeks later, the performances were desastrous. 30 seconds to get an answer to a simple select on a 1500 entries tables. After investigation, the problems were: - no vacuum, although there were daily DELETE FROM tables; to empty all the data and reload from another source. - no analyze, because the admin did not know about it. My goal is to have pg_autovacuum integrated into the backend for 7.5. I don't know if it will default to being turned on or off, I'm sure that will be a discussion, but if it is defaulted to on, then this whole problem of having to train newbies about vacuum should just go away. Matthew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html !DSPAM:40892fd393131228097780! -- Dave Cramer 519 939 0336 ICQ # 14675561 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [pgsql-advocacy] What can we learn from MySQL?
On Fri, 23 Apr 2004, Bruce Momjian wrote: Here is a blog about a recent MySQL conference with title, Why MySQL Grew So Fast: http://www.oreillynet.com/pub/wlg/4715 and a a Slashdot discussion about it: http://developers.slashdot.org/article.pl?sid=04/04/20/2229212mode=nestedtid=137tid=185tid=187tid=198 My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. My immediate rhetorical response is What could the Tortoise learn from the Hare? I think we all know which is which in my question. Questions I have are: o Are we marketing ourselves properly? I'm never sure about this. I think the best marketing is experienced users selling pg to their bosses one at a time. While our MSSQL servers at work have died under load innumerable times, our small collection of postgresql servers (one's so old and embedded it's running 6.4) have been very reliable. So, slowly but surely, PostgreSQL is proving itself here. o Are we focused enough on ease-of-use issues? Enough for me, but I don't think databases should necessarily be all that easy to use by people who don't understand basic relational theory. So for me, ease of use means things like transactable DDL and well indexed, well written documentation. I suspect ease of use for my boss is something entirely differnt, and may have to do with why he bought the EMS postgresql manager packages he did. o How do we position ourselves against a database that some say is good enough (MySQL), and another one that some say is too much (Oracle) Hey, we're like the porridge in goldilock's, just right... :-) dba folks don't pick MySQL, because it's so limited and basically has so many bugs (it's a feature that we don't bounds check data!) And it's pretty easy to get an Oracle guy to play with postgresql when you show him things like transactionable DDL. o Are our priorities too technically driven? I don't think so. But I'm a database / coder geek. :-) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, 23 Apr 2004, Robert Treat wrote: On Fri, 2004-04-23 at 05:22, Dennis Bjorklund wrote: On Fri, 23 Apr 2004, Shachar Shemesh wrote: When I ask about non-standard complience of Pg (turning unquoted identifiers to lowercase instead of uppercase, violating the SQL standard, and requring an expensive rewrite of clients), and I get the answer uppercase is ugly, I think something is wrong. I would love if someone fixed pg so that one can get the standard behaviour. It would however have to be a setting that can be changed so we are still backward compatible. that even if I write a patch to start migration, I'm not likely to get it in. Just changing to uppercase would break old code so such a patch should not just be commited. But would people stop a patch that is backward compatible (in the worst case a setting during initdb)? I'm not so sure they will. I know this to be true, but don't fully understand it... if our default behavior is to fold lower, and we change it to just fold upper... then in theory this shouldn't break anything since what used to be folder lower will now simply be folder upper. the only people who will have a problem are those who quote on one end but not the other, which is bad practice anyways... so i would say if your serious about it, make the patch as GUC case_folding for upper or lower and get a taste for what breaks inside the db. I've tried just changing the parser to unconditionally casefold to upper. First thing that happens is that initdb breaks. In addition, you have potential issues with comparisons against the catalog's versions of standard functions as such if you allow the case folding to be changed after the catalogs are setup. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] What can we learn from MySQL?
On Fri, 23 Apr 2004 11:07:20 -0400 Dave Cramer [EMAIL PROTECTED] wrote: Does the current implementation of pg_autovacuum have a way of setting windows where it is allowed to vacuum? Many large 24/7 will only allow vacuumming at certain times of the day. It seems to me that the point of pg_autovacuum would be to run 24/7 so that there is never big hit on the system. Perhaps it could be designed to throttle itself based on current system usage though. -- D'Arcy J.M. Cain [EMAIL PROTECTED]|vex}.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] What can we learn from MySQL?
Does the current implementation of pg_autovacuum have a way of setting windows where it is allowed to vacuum? Many large 24/7 will only allow vacuumming at certain times of the day. No the current implementation doesn't, but such a feature is in the works (planned anyway). What I was envisioning is the ability to set two different sets of thresholds (peak / off peak). If you demand zero vacuuming during peak times, you could set that threshold to -1, or some such setting. FYI I wouldn't remcommend defaulting pg_autovacuum to on until it does this, and a few more things that are also planned (see the archives). Matthew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] What can we learn from MySQL?
On Fri, 23 Apr 2004 11:07:20 -0400 Dave Cramer [EMAIL PROTECTED] wrote: Does the current implementation of pg_autovacuum have a way of setting windows where it is allowed to vacuum? Many large 24/7 will only allow vacuumming at certain times of the day. It seems to me that the point of pg_autovacuum would be to run 24/7 so that there is never big hit on the system. Perhaps it could be designed to throttle itself based on current system usage though. Right, there has been some talk about taking the system load into account, but no action yet. One comment I failed to make in my last email was that there should be less need to explictly disallow vacuum during peak periods since vacuum will only be occuring on specific tables when needed, which will effect the server for a much smaller period of time than a general vacuum command that touches all the tables. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Stephan Szabo wrote: I know this to be true, but don't fully understand it... if our default behavior is to fold lower, and we change it to just fold upper... then in theory this shouldn't break anything since what used to be folder lower will now simply be folder upper. the only people who will have a problem are those who quote on one end but not the other, which is bad practice anyways... so i would say if your serious about it, make the patch as GUC case_folding for upper or lower and get a taste for what breaks inside the db. I've tried just changing the parser to unconditionally casefold to upper. First thing that happens is that initdb breaks. In addition, you have potential issues with comparisons against the catalog's versions of standard functions as such if you allow the case folding to be changed after the catalogs are setup. ISTM that rather than a having a GUC setting, initdb would be the right time to make this choice. I'm not saying it would be easy, but it seems (without looking into it deeply) at least possible. cheers andrew ---(end of broadcast)--- TIP 3: 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] What can we learn from MySQL?
D'Arcy J.M. Cain wrote: On Fri, 23 Apr 2004 11:07:20 -0400 Dave Cramer [EMAIL PROTECTED] wrote: Does the current implementation of pg_autovacuum have a way of setting windows where it is allowed to vacuum? Many large 24/7 will only allow vacuumming at certain times of the day. It seems to me that the point of pg_autovacuum would be to run 24/7 so that there is never big hit on the system. Perhaps it could be designed to throttle itself based on current system usage though. Or the number of connected backends, or both? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] What can we learn from MySQL?
On Fri, 23 Apr 2004 13:08:30 -0400 (EDT) Bruce Momjian [EMAIL PROTECTED] wrote: D'Arcy J.M. Cain wrote: It seems to me that the point of pg_autovacuum would be to run 24/7 so that there is never big hit on the system. Perhaps it could be designed to throttle itself based on current system usage though. Or the number of connected backends, or both? I am sure that there are lots of ways to guage. Not sure which is best but I am sure that the smart people here will figure it out. The important thing, I think, is to let the engine make the decision dynamically. Personally I don't have a quiet time per se but there are random quiet periods. Something that jumps into the fray at those points would be really nicwe. -- D'Arcy J.M. Cain [EMAIL PROTECTED]|vex}.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] PITR, nested transactions, tablespaces, 2-phase commit: Status
On Sat, 17 Apr 2004, Bruce Momjian wrote: Would folks report on the current status of these projects: o nested transactions (Alvaro Herrera) o tablespaces (Gavin Sherry) o PITR (Simon Riggs) o 2-phase commit (Heikki Linnakangas) I've been very busy with at work, and haven't had much time to work on the 2-phase commit patch. I'm keeping a close eye on Alvaro's nested transactions stuff, because it touches the same areas as 2-phase commits. One day, while reading postgresql code, I realized that my two-phase code doesn't do the right thing with snapshots. GetSnapshotData scans through all running backends, and collects the xids of all running transactions. I suppose all pre-committed transactions should go to the snapshot too. So there's still some work to be done, but I'm still hoping to finish it in time for 7.5. - Heikki ---(end of broadcast)--- TIP 3: 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] contrib vs. gborg/pgfoundry for replication solutions
On Fri, 2004-04-23 at 11:02, Rod Taylor wrote: On Thu, 2004-04-22 at 23:05, Robert Treat wrote: On Thursday 22 April 2004 13:55, Barry Lind wrote: I think the solution lies in improving www.postgresql.org. At the end of the day it doesn't matter where source code lives, what matters is can people find what they are expecting. Given we know what people are looking for, that should be front and center on the web site and the ftp sites. But of course that solution always stalls out when it comes down to picking which projects get the special treatment of direct links from the main website and which ones stay out of the spotlight. With JDBC you might make I really don't see this as being any different than deciding which buffer strategy or website style to use. One is better in some way so it becomes a part of the system. The difference is that a better admin tool is very subjective where as a buffer strategy is not... or maybe the difference is really that everyone thinks they are qualified to pick a better admin tool, but very few can really argue as to a better buffer strategy. While I think your criteria is pretty close to what I would use, I still couldn't pick which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql... and even I did I bet some people would have a problem with my choices. Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, 2004-04-23 at 13:11, Andrew Dunstan wrote: Stephan Szabo wrote: I know this to be true, but don't fully understand it... if our default behavior is to fold lower, and we change it to just fold upper... then in theory this shouldn't break anything since what used to be folder lower will now simply be folder upper. the only people who will have a problem are those who quote on one end but not the other, which is bad practice anyways... so i would say if your serious about it, make the patch as GUC case_folding for upper or lower and get a taste for what breaks inside the db. I've tried just changing the parser to unconditionally casefold to upper. First thing that happens is that initdb breaks. In addition, you have potential issues with comparisons against the catalog's versions of standard functions as such if you allow the case folding to be changed after the catalogs are setup. ISTM that rather than a having a GUC setting, initdb would be the right time to make this choice. I'm not saying it would be easy, but it seems (without looking into it deeply) at least possible. This implies that the standard functions are created with explicit quoting to make the lower case named? Shouldn't all functions be created without any quoting so they fold to whichever way the settings are set? Hmm... I see your angle Andrew.. they are going to be created one way or the other so you'd be hard pressed to do it at any time other than initdb time... of course you could just create duplicates of all the functions in both upper and lower case, that way whichever way you fold it matches :-) Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Robert Treat wrote: On Fri, 2004-04-23 at 13:11, Andrew Dunstan wrote: Stephan Szabo wrote: I know this to be true, but don't fully understand it... if our default behavior is to fold lower, and we change it to just fold upper... then in theory this shouldn't break anything since what used to be folder lower will now simply be folder upper. the only people who will have a problem are those who quote on one end but not the other, which is bad practice anyways... so i would say if your serious about it, make the patch as GUC case_folding for upper or lower and get a taste for what breaks inside the db. I've tried just changing the parser to unconditionally casefold to upper. First thing that happens is that initdb breaks. In addition, you have potential issues with comparisons against the catalog's versions of standard functions as such if you allow the case folding to be changed after the catalogs are setup. ISTM that rather than a having a GUC setting, initdb would be the right time to make this choice. I'm not saying it would be easy, but it seems (without looking into it deeply) at least possible. This implies that the standard functions are created with explicit quoting to make the lower case named? Shouldn't all functions be created without any quoting so they fold to whichever way the settings are set? Hmm... I see your angle Andrew.. they are going to be created one way or the other so you'd be hard pressed to do it at any time other than initdb time... of course you could just create duplicates of all the functions in both upper and lower case, that way whichever way you fold it matches :-) That strikes me as an instant recipe for shooting yourself in the foot, as well as providing useless catalog bloat. Things need *one* canonical name, IMNSHO. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PITR, nested transactions, tablespaces, 2-phase commit:
Just so you know I'm very thankful for your hard work and I'm sure many of us are. I have been waiting for this kind of functionally in Postgresql! |-+-- | | Heikki Linnakangas | | | [EMAIL PROTECTED] | | | Sent by: | | | [EMAIL PROTECTED]| | | tgresql.org| | | | | | | | | 04/23/2004 12:56 PM| | | | |-+-- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: [HACKERS] PITR, nested transactions, tablespaces, 2-phase commit: Status | | On Sat, 17 Apr 2004, Bruce Momjian wrote: Would folks report on the current status of these projects: o nested transactions (Alvaro Herrera) o tablespaces (Gavin Sherry) o PITR (Simon Riggs) o 2-phase commit (Heikki Linnakangas) I've been very busy with at work, and haven't had much time to work on the 2-phase commit patch. I'm keeping a close eye on Alvaro's nested transactions stuff, because it touches the same areas as 2-phase commits. One day, while reading postgresql code, I realized that my two-phase code doesn't do the right thing with snapshots. GetSnapshotData scans through all running backends, and collects the xids of all running transactions. I suppose all pre-committed transactions should go to the snapshot too. So there's still some work to be done, but I'm still hoping to finish it in time for 7.5. - Heikki ---(end of broadcast)--- TIP 3: 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 * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
The difference is that a better admin tool is very subjective where as a buffer strategy is not... or maybe the difference is really that everyone thinks they are qualified to pick a better admin tool, but very few can really argue as to a better buffer strategy. While I think your criteria is pretty close to what I would use, I still couldn't pick which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql... and even I did I bet some people would have a problem with my choices. If you have a hard time picking between those projects, imagine the difficulties someone who has never used PostgreSQL has just tracking down the options available to them. We would not be removing any choices for the user. We're simply supplying a list of suggested tools that they may have interest in. Getting the user to download PostgreSQL and give it a shot without becoming frustrated because the basics were not available (in an obvious location) is the first step. Step 2 is to inform the user that there are more alternatives available. I see pgFoundary doing a good job of #2 -- but it is not going to help with #1 (too much choice is as bad as none at all to a beginner). ---(end of broadcast)--- TIP 3: 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] What can we learn from MySQL?
On Thu, 2004-04-22 at 21:09, Bruce Momjian wrote: Questions I have are: o Are we marketing ourselves properly? It is perhaps less a matter of marketing and more a matter of word-of-mouth mind share. I don't see much evidence of effective direct marketing, but I've noticed a huge growth in mind share among the technical crowd over the last few years, which appears to be an outgrowth of technical reputation. o Are we focused enough on ease-of-use issues? No, and I think this is THE biggest impediment to popularity. The real question should actually be ease-of-use for who?. I had little difficulty adapting to Postgres because I have tons of database experience and so I knew what I was looking for in the technical documentation, which is quite good for an experienced person. But I have noticed that most people who have a much more limited experience with RDBMS administration have a hard time getting started because the use curve is pretty steep. Ease of use isn't an issue for people like me -- I find it very easy -- but is a significant hurdle for most everyone else e.g. casual developers. Some specific recommendations on this: - Make a standard GUI admin tool a prominent part of the standard Postgres distribution, something along the lines of pgAdmin. I don't use it, but a lot of other people need it. For casual database developers, this will greatly enhance apparent ease of use. - Pick a procedural language (plpgsql would seem like the obvious choice) and make it a standard part of a Postgres installation. A standard procedural language should be an out-of-the-box feature that just works. Standard connection drivers (JDBC, ODBC, etc) should also be installed by default and visible to the user. Doing a standard installation of Postgres for most people requires collecting a half dozen bits and pieces that would be installed by default or as install-time options for many databases. - Make it much easier for the relatively clueless to install options in their database. Having an official menu of popular add-on modules (e.g. some of the contrib stuff), and an easy way to automagically enable these capabilities, will serve to educate users that these features exist and encourage their use. I find that most new Postgres users aren't aware that any of these things exist outside of whatever was included with a vanilla install. - Expanded documentation and well-indexed how-tos, both for the database itself and for building applications using the database, for people who are clueless about the technical details of Postgres internals would be helpful. The standard documentation tree is a bit too reference-y for less experienced people, and makes certain contextual assumptions that I find many less experienced trying to navigate it don't have. There is a gap in the documentation between total n00b and experienced DBA that makes it hard to transition that gap. Postgres actually has very good ease-of-use for experienced DBAs, which is something that it definitely gets right. And comparing a Postgres installation to an Oracle installation is like night and day. The problem is that there is no easy bootstrap path for people who aren't so experienced with database administration and maintenance in general. o How do we position ourselves against a database that some say is good enough (MySQL), and another one that some say is too much (Oracle) Postgres should be positioned as an effective alternative to Oracle, and the focus should be on the enterprise database space. Postgres has some significant leverage points in the enterprise database space, even today, and as it becomes more feature-complete it will increasingly become a compelling choice within this space. Comparing Postgres to MySQL is a mistake IMO, as it leads people to assume that they are roughly equivalent products. I actually read a very recent Gartner Group report comparing Postgres and MySQL a couple months ago that basically said that Postgres and MySQL are equivalent products, but MySQL is easier to use. And their reasoning basically cited the myriad of MySQL versus Postgres comparisons on the 'net. The suits who did the research had difficulty evaluating the technical merits and so they based relative equivalence on the fact that they were constantly compared to each other in the same light. From a marketing standpoint, I would focus all my effort on comparisons to commercial enterprise DB engines like Oracle and ignore MySQL. This will define Postgres as a part of the enterprise market and remove it from the same market space that MySQL occupies. o Are our priorities too technically driven? No. The greatest strength of Postgres, marketing-wise, are technical and is what drives its growth today. I think most of the ease-of-use issues are in the packaging of the larger Postgres product and mid-level developer documentation, both of which seem to be eminently
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, 2004-04-23 at 14:28, Andrew Dunstan wrote: Robert Treat wrote: of course you could just create duplicates of all the functions in both upper and lower case, that way whichever way you fold it matches :-) That strikes me as an instant recipe for shooting yourself in the foot, as well as providing useless catalog bloat. Things need *one* canonical name, IMNSHO. hence the smiley... Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] What can we learn from MySQL?
J. Andrew Rogers wrote: No. The greatest strength of Postgres, marketing-wise, are technical and is what drives its growth today. I think most of the ease-of-use issues are in the packaging of the larger Postgres product and mid-level developer documentation, both of which seem to be eminently solvable problems. I think improved default product packaging would remove 80% plus, up to this point AFAIK the postgresql docs have not been quoted here: http://www.dbdebunk.com which speaks volumes ;) Merlin ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
On Thu, 2004-04-22 at 23:05, Robert Treat wrote: The difference is that a better admin tool is very subjective where as a buffer strategy is not... or maybe the difference is really that everyone thinks they are qualified to pick a better admin tool, but very few can really argue as to a better buffer strategy. While I think your criteria is pretty close to what I would use, I still couldn't pick which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql... and even I did I bet some people would have a problem with my choices. I think the issue is that is gborg/pgfoundy should not just be a sourceforge like tool for postgresql related applications. If they are then someone looking for a gui admin tool for exmaple has to try them all out only to find that 75% of them are half started projects that haven't been maintained in two years, at least that is my typical experience with sourceforge, and I know that is an issue with gborg right now. Perhaps we could have some type of system whereby we can rank apps that as tier1 supported or some such thing. The end user can still make his subjective choice as to which is best, since nothing prevents us from having 4 different tier1 supported gui admin apps, but the enduser would be able to weed out most of the apps that aren't even close. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Rod Taylor [EMAIL PROTECTED] writes: The difference is that a better admin tool is very subjective where as a buffer strategy is not... or maybe the difference is really that everyone thinks they are qualified to pick a better admin tool, but very few can really argue as to a better buffer strategy. While I think your criteria is pretty close to what I would use, I still couldn't pick which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql... and even I did I bet some people would have a problem with my choices. If you have a hard time picking between those projects, imagine the difficulties someone who has never used PostgreSQL has just tracking down the options available to them. Exactly. MySQL makes no bones about choosing blessed projects. I don't think that MySQL AB's MySQL Control Center is the best MySQL GUI, but it's better than the default PostgreSQL choice. MySQL shoves a workable solution under the end user's nose. PostgreSQL gives the potential user a wide array of choices, none of which are particularly easy to find. How many GUI tools are listed on GBorg? How many potential users even know to look at GBorg at all? One thing is certain most users aren't going to find psql (probably compiled without readline support) comparable with MySQL Control Center. Not to mention the fact that not having a set of blessed tools means that we end up with competing tools. PostgreSQL has several replication toolsets, piles of admin tools, and several competing language bindings for some of the most popular development languages. How many Python bindings does PostgreSQL need? PostgreSQL has some amazing supporting tools, but they are all hidden in an unlighted basement in a locked filing cabinet next to a sign that reads Beware of the Leopard. We would not be removing any choices for the user. We're simply supplying a list of suggested tools that they may have interest in. Exactly. Yes, choosing tools requires some politics, and it will inevitably make some users and developers upset because their projects will get passed over for more popular ones. However, this will certainly help new users that are looking at PostgreSQL for the first time. They will be able to see, right off, what *sort* of tools are available for use with PostgreSQL. Later on as these people become part of the PostgreSQL community they might even find out about alternative tools that they like better. Getting the user to download PostgreSQL and give it a shot without becoming frustrated because the basics were not available (in an obvious location) is the first step. PostgreSQL stacks up well as a database. In fact, it rocks. But comparing plain Jane PostgreSQL against other databases and their assorted suite of tools is not going to work in PostgreSQL's favor. Fortunately PostgreSQL has comparable supporting tools as well. Unfortunately no one knows about these tools except for those of us on the PostgreSQL lists. Step 2 is to inform the user that there are more alternatives available. I see pgFoundary doing a good job of #2 -- but it is not going to help with #1 (too much choice is as bad as none at all to a beginner). Precisely. The trick is to promote PostgreSQL and a core set of tools. These tools don't have to be part of PostgreSQL's CVS (or even be available for download) from the postgresql.com site, but they should receive top billing. When the end user looks for a GUI, there should be a single solitary GUI that should be the default choice. When the end user asks about replication they should be guided to a single solution. In cases where it is difficult to decide what the default case might be--like in the case of replication where the tools you will want to use depends on what you are trying to accomplish--simply point users at the most common scenario and then document that they might need to use other tools to solve different problems. Jason ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [pgsql-advocacy] What can we learn from MySQL?
On Fri, Apr 23, 2004 at 02:35:48PM +0800, Christopher Kings-Lynne wrote: My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. Questions I have are: I have already told Bruce at length about the single most common complaint in the phpPgAdmin lists and in the IRC channel: the inability to change column types. I think we should listen to the punters on that one. Also, how about a new section in the manual: PostgreSQL for MySQL users and PostgreSQL for Oracle users? Maybe also a more generic section about how PGSQL is different from other databases. Maybe I'm just dense, but it took me a long time to figure out the whole lack of stored procedures thing (yes, PGSQL obviously has the functionality, but many experienced DBAs won't associate functions with stored procs). Pointing out the documentation on MVCC and how it changes how you want to use the database would be good, as would links to documentation on what postgresql.conf settings you want to change out of the box. On the other topics... I think the biggest service PGSQL could provide to the open source community is a resource that teaches people with no database experience the fundamentals of databases. If people had an understanding of what a RDBMS should be capable of and how it should be used, they wouldn't pick MySQL. Having a windows port is critical for 'student mindshare'. If PGSQL can't play on windows, professors can't use it. Likewise, installation on OS X should be made as easy as possible. That's for the 'low end' users (many of whom will eventually become 'high end'). For professionals who have database expertise, the comparison guide will help a lot. The other thing that will help is continuing to bring enterprise-class features in, like multi-master replication, partitioning, and clustering. But since people tend to think most about the technology, I'm sure those will make it in eventually anyway. :) -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
On Fri, Apr 23, 2004 at 01:05:40AM -0300, Marc G. Fournier wrote: This is all I'm saying ... its like when we packaged up our first eRServer ... I didn't require our clients to go out and download PostgreSQL to build it, I pulled in the few files from our build environment into the package so that it could be built independently ... I am the last person in the world to cast aspersions on anyone's packaging, but I'm not sure holding erserver up as a paradigm case of easy compilation outside the main build tree is going to make your argument easier here. A -- Andrew Sullivan | [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Stephan Szabo wrote: I've tried just changing the parser to unconditionally casefold to upper. First thing that happens is that initdb breaks. In addition, you have potential issues with comparisons against the catalog's versions of standard functions as such if you allow the case folding to be changed after the catalogs are setup. That's not the migration path I was thinking of. What I was thinking of was: 1. Have a setting, probably per-session. Per database works too. 2. Aside from the folder upper and folder lower, have a third option. This is fold upper, if fails, fold lower. If succeeds, issue a warning. This should allow programs that rely on the folding (such as initdb) to be debugged during the transition period. Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] pgFoundry delayed -- some setup issues
Folks, Well, as someone could have predicted, once we actually tried running some new projects on pgFoundry we ran into setup issues.We're resolving these and should have stuff up and running soon. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, 23 Apr 2004, Shachar Shemesh wrote: Stephan Szabo wrote: I've tried just changing the parser to unconditionally casefold to upper. First thing that happens is that initdb breaks. In addition, you have potential issues with comparisons against the catalog's versions of standard functions as such if you allow the case folding to be changed after the catalogs are setup. That's not the migration path I was thinking of. What I was thinking of was: 1. Have a setting, probably per-session. Per database works too. 2. Aside from the folder upper and folder lower, have a third option. This is fold upper, if fails, fold lower. If succeeds, issue a warning. This should allow programs that rely on the folding (such as initdb) to be debugged during the transition period. If you can do this in a clean fashion without tromping all around the code, that'd be reasonable, however, istm that you'd need to either pre-fold both directions from the given identifier string and pass an extra copy around or pass the original identifier and its quoted status and fold on use. I think either of these are likely to be very intrusive for what essentially amounts to a transitional feature. In addition, I'm not sure that this would always work in any case, since some of those usages may be quoted identifiers that were once generated from a case-folded string (for example, looking up a name in the catalogs and quoting it). ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] What can we learn from MySQL?
I have been thinking about this subject for a LONG time, and I hope I have something to contribute. My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. Questions I have are: o Are we marketing ourselves properly? I would say this is a clear 'NO!' When ever I read about open-source being used anywhere, I always read MySQL. They are *very* good at this. o Are we focused enough on ease-of-use issues? Again, NO! To often you guys settle for a work-around rather than a feature. You are satisfied that symlinks will do the job. When someone says they want a feature, you say, no - use a symlink. Ease of use is VERY important, but few suggestions that address this are ever really accepted. Yes, focusing on the functionality is the primary concern, but how you set it up and deploy it is VERY important. You guys need to remember, people are coming from a world where MySQL, Oracle, and MSSQL all have nice setup programs. I know a bit about this, as I made a PostgreSQL for Windows (It was 7.3.x) CD a while back. I had to do a lot of work on the postgresql configuration, database initialization, and create a demo database. It used a minimal cygwin environment, a Windows based installer, and some custom function libraries. I tried to submit the configuration patch and all I got was argument about using symlinks or how it wasn't needed. The thing that kind of bugs me about this O/S project is that you guys are a bit nit-picking about how someone uses it. I believe in the UNIX phylosophy: capability not policy, flexability, etc. You guys seem to need an absolute reason to include something, rather than a good reason to exclude something. A lot of open source developers are turned off by this sort of attitude. o How do we position ourselves against a database that some say is good enough (MySQL), and another one that some say is too much (Oracle) My argument against this is that MySQL is no less complicated than PostgreSQL. PostgreSQL, in production is faster than MySQL, even though MySQL may be marginally faster on some simple queries. The system resource usage of both systems is very similar. PostgreSQL, however, boasts a lot of standard features that make using it much easier. o Are our priorities too technically driven? For the most part, you guys do a great, no .. fantastic, job at the technical details of the database. Even though I get frustrated, I know it is a great system. You *should* be technically driven. If you want to blow the competition out of the water, you need a non-forked Windows version of the database. You need a Java (or some other portable environment) installer. You need to get out of the hand-administered mentality of using symlinks and system level constructs. One should be able to install the software, bring up a nice configuration program which runs you through a few questions, and be done. This same configuration program should be able to help maintain and control an the installation. On Windows, have a service monitor program that starts and stops the server, on UNIX, have it able to start/stop via init.d. Everything else is expert level. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, 23 Apr 2004, Stephan Szabo wrote: On Fri, 23 Apr 2004, Shachar Shemesh wrote: Stephan Szabo wrote: I've tried just changing the parser to unconditionally casefold to upper. First thing that happens is that initdb breaks. In addition, you have potential issues with comparisons against the catalog's versions of standard functions as such if you allow the case folding to be changed after the catalogs are setup. That's not the migration path I was thinking of. What I was thinking of was: 1. Have a setting, probably per-session. Per database works too. 2. Aside from the folder upper and folder lower, have a third option. This is fold upper, if fails, fold lower. If succeeds, issue a warning. This should allow programs that rely on the folding (such as initdb) to be debugged during the transition period. If you can do this in a clean fashion without tromping all around the code, that'd be reasonable, however, istm that you'd need to either pre-fold both directions from the given identifier string and pass an extra copy around or pass the original identifier and its quoted status and fold on use. I think either of these are likely to be very intrusive for what essentially amounts to a transitional feature. In addition, I'm not sure that this would always work in any case, since some of those usages may be quoted identifiers that were once generated from a case-folded string (for example, looking up a name in the catalogs and quoting it). To clarify, I'm thinking about things where an application had gotten a quoted name and is now trying to use it where the object's canonical name was changed due to quoting changes. This only happens when quoting is inconsistently applied, but that's most of the problem. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] What can we learn from MySQL?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, - -- Bruce Momjian [EMAIL PROTECTED] wrote: o Are we marketing ourselves properly? while talking about MySQL, there is the myth, that MySQL is fast; and that because MyISAM has no transactions, that it is faster. That is in most cases not true! And for all real live scenarios I know and I tested, Postgres was faster. An example: a critical calculation in one of my online projects needs with MySQL (MyISAM Table Type) about 2.7 to 2.8 seconds (group by on 50 rows for some realtime statistics). But on this time, the complete table is write locked (because MyISAM) :-( With InnoDB the same needs at least 15 to 20 seconds, but other users can insert/update. With PostgreSQL (7.4) it took 1.9 to 2 seconds. Parallel inserts/updates no problem. The only reason why I changed the whole stuff to Postgres yet is, that there are a lot of problems with MySQL special features (see the Gotchas: http://sql-info.de/mysql/gotchas.html) Other example: Some days ago I had a talk with my project leader; I said, that for a new application we should *everything* build with transactions, referential integrity, ... -- his answer: I want to have a fast application. AAARRGH! ;-( So, perhaps it might be a good idea to create a page with feature- and performance comparison. I planed to create an independant and RDBMS benchmark suite (as Free Software including the datas for testing), but I'm not sure if this project ever come true ... o Are we focused enough on ease-of-use issues? I'm not sure about the focus; but the result can be better. When installing and using any type of software, I want that this is as easy as possible while it helps me to understand as much of the backgrounds as possible. Whats about the initdb, postgresql.conf and startup scripts? So, It might be good to have a GUI-Tool (!) in the standard package, which makes an initdb with selectable options and helps the user to set the required options in the postgresql.conf. I'm a computer freak since the mod 80s and I can edit config files. But to have a GUI tool with some explaining texts at the buttons etc is much easyer than hacking a textfile. Also the other stuff mentioned in this thread are important: auto vacuum, windows port, better default values etc. Ease-of-use includes for me localisation and documentation in different languages. As you can see, my english is junky -- so reading german documentation is a lot of easyer for me ;-) o Are our priorities too technically driven? AFAIK it is good to have the priorities technically driven -- if nobody forgets the userfriendlyness ;) Ciao Alvar - -- ** Alvar C.H. Freude -- http://alvar.a-blast.org/ -- http://odem.org/ ** Berufsverbot? http://odem.org/aktuelles/staatsanwalt.de.html ** ODEM.org-Tour: http://tour.odem.org/ ** 5 Jahre Blaster: http://www.a-blast.de/ | http://www.a-blast.de/statistik/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAiX/eOndlH63J86wRAjzhAJ0f24+yuOSElI7NmFuChZUH3miWiACdFoH+ OLC0iUn7VP/ZIA30vU8M0tg= =RVWf -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] What can we learn from MySQL?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, - -- [EMAIL PROTECTED] wrote: I would say this is a clear 'NO!' When ever I read about open-source being used anywhere, I always read MySQL. They are *very* good at this. yes! Some days ago, there was a news in the Heise Newsticker (most important IT news in germany), about MySQL clustering. http://www.heise.de/newsticker/meldung/46511 4*2 processors with 10 replicated transactions per second was the main statement. I'm sure, that this is the typical MySQL blabla: no transactions, but select statements ... http://www.heise.de/newsticker/foren/go.shtml?read=1msg_id=5487088forum_id =55321 I'm not sure, if iot is a good idea to go down with the niveau to such lies. o Are we focused enough on ease-of-use issues? Again, NO! To often you guys settle for a work-around rather than a feature. You are satisfied that symlinks will do the job. When someone says they want a feature, you say, no - use a symlink. [...] yes, you are right! One additional thing: when updating from 7.x to 7.y, a new initdb is needed. This means: If I have some GB Data, the RDBMS is some ours down for upgrading. This is really no good situation. There should be a way for converting the storage on the fly: Updating and let postgres do the rest automaically. I guess this is not really easy; but it is important! Ciao Alvar - -- ** Alvar C.H. Freude -- http://alvar.a-blast.org/ -- http://odem.org/ ** Berufsverbot? http://odem.org/aktuelles/staatsanwalt.de.html ** ODEM.org-Tour: http://tour.odem.org/ ** 5 Jahre Blaster: http://www.a-blast.de/ | http://www.a-blast.de/statistik/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAiYcpOndlH63J86wRAoj7AKCt+SXIV/1UYa7hZlEpA1SrwpctnQCgpypM 2L5aRteQ7btVuBowcclBc28= =POHj -END PGP SIGNATURE- ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] License question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Shachar Shemesh [EMAIL PROTECTED] wrote: The new requirement encapsulates the original requirement, and your license is therefor not violated. I have, in fact, relicensed your work. no, the license is only for the *combined* work (which includes your work). Extracting the original picture, this picture is still under the blue only license! Ciao Alvar - -- ** Alvar C.H. Freude -- http://alvar.a-blast.org/ -- http://odem.org/ ** Berufsverbot? http://odem.org/aktuelles/staatsanwalt.de.html ** ODEM.org-Tour: http://tour.odem.org/ ** 5 Jahre Blaster: http://www.a-blast.de/ | http://www.a-blast.de/statistik/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAiYs5OndlH63J86wRAjflAJ9Tpg6QvvVJTRAThq42b5oXXmxkqgCfSv08 CsS0RzWeFzgtAfcOZq+x/Po= =Lhtc -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Current CVS tip segfaulting
Hackers, In current (as of a couple hours ago) clean CVS tip sources, without any of my local changes, I'm getting a postmaster segfault when trying to connect to a non existant database. The generated core file does not seem to contain any useful information. The first time I saw this I managed to PANIC the system -- I can't seem to be able to reproduce that part. (Newly built on an empty vpath, so this should be a case of make distcleaning ...) Core was generated by `postgres: alvherre asd [local] startup '. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /lib/libz.so.1...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /lib/libreadline.so.4.3...done. Loaded symbols for /lib/libreadline.so.4.3 Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/libgpm.so.1...done. Loaded symbols for /lib/libgpm.so.1 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/lib/gconv/ISO8859-15.so...done. Loaded symbols for /usr/lib/gconv/ISO8859-15.so Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so 0x in ?? () (gdb) bt #0 0x in ?? () -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) The only difference is that Saddam would kill you on private, where the Americans will kill you in public (Mohammad Saleh, 39, a building contractor) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Current CVS tip segfaulting
Please recompile with debug symbols and report back the stack trace. See the faq on running debug. --- Alvaro Herrera wrote: Hackers, In current (as of a couple hours ago) clean CVS tip sources, without any of my local changes, I'm getting a postmaster segfault when trying to connect to a non existant database. The generated core file does not seem to contain any useful information. The first time I saw this I managed to PANIC the system -- I can't seem to be able to reproduce that part. (Newly built on an empty vpath, so this should be a case of make distcleaning ...) Core was generated by `postgres: alvherre asd [local] startup '. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /lib/libz.so.1...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /lib/libreadline.so.4.3...done. Loaded symbols for /lib/libreadline.so.4.3 Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/libgpm.so.1...done. Loaded symbols for /lib/libgpm.so.1 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/lib/gconv/ISO8859-15.so...done. Loaded symbols for /usr/lib/gconv/ISO8859-15.so Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so 0x in ?? () (gdb) bt #0 0x in ?? () -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) The only difference is that Saddam would kill you on private, where the Americans will kill you in public (Mohammad Saleh, 39, a building contractor) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Threading for 7.5
I have completed most of the thread changes listed below. I have added automatic thread compile/link flag detection via configure from the URL listed below. I have kept per-platform customization that was used in the past. Please let me know of the new flag usage (like -pthread) makes your platform's template flags unneeded. I have also added code to the bottom of configure to run src/tools/thread_test for threaded builds and throw an error if the platform doesn't support threads. I have greatly improved the thread test program. It now does only the tests that are required for that platform, rather than all thread functions we might need. I talked to Peter via chat and he seemed to be OK with it. He didn't like running the test program from initdb or putting it in /bin, and wanted it done as part of configure. I am sure this will need adjustment, but for now, I think it looks good. I have also added a doc mention that folks run the thread test program if they are experiencing problems with threading. Folks, please test and let me know how it works for your platform. [ I think for Unixware we are going to need to use the thread flags for building all binaries. It will be easy to do. Larry, you read to test a patch?] --- pgman wrote: As you know, we had libpq and ecpg threading available in 7.4 via a configure flag. However, threading required users to report their platform's configure flags (something better done by configure) and run a thread test program (src/tools/thread/thread_test). For 7.5, I want to use: http://www.gnu.org/software/ac-archive/htmldoc/acx_pthread.html that Jan found that is a plug-in for configure to determine thread flags. As long as it has the existing platform flags we know about, this will be a better way to determine threading flags. The thread-test program is works, but it tests only one version of each operating system. Ideally is should be run on the build/install machine, rather than have a per-port value. I talked via chat with Peter on this, and running this from configure again only tests the current library, and doesn't handle cross-compiling or cases where a different version of the dynamic library is used for binary distributions. The basic problem is that thread_test tests _how_ functions get their results (thread-safe or not), and not the actual input/output of the function. I want to do away with per-platform testing for thread_test. If the platform supports threading, it should pass that test. I have updated its output to be cleaner: Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS' defines to your template/$port file before compiling this program. errno is thread-safe Your system uses strerror() which is thread-safe. Your system has getpwuid_r(), so it doesn't use getpwuid(). Your system has getaddrinfo(), so it doesn't use gethostbyname() or gethostbyname_r(). YOUR PLATFORM IS THREADSAFE It reports the system as thread safe or not thread-safe. I think we can just tell folks to run that test if they are going to use threads or if they are having problems with threads. We can mark platform versions that are _not_ thread safe, rather than enable platforms only after they have passed the test. If it doesn't pass, the platform is broken for threads. The idea is that any platform that supports threads _should_ pass the test. Assuming that many will fail is not efficient for us, and perhaps not reliable either. Peter asked about binary-only distributions, and how they would run the thread test program. Perhaps when threading is enabled in configure, we should actually install the thread test program as pg_thread_test in /bin along with the other PostgreSQL binaries. Folks who want to use threads should run that program first to test things. With these changes, all platforms should be able to enable threads, and we will not have to collect per-platform thread reports for 7.5, except collect platform versions that are not thead-safe and put those tests in the template files. Comments? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Current CVS tip segfaulting
On Fri, Apr 23, 2004 at 07:00:05PM -0400, Bruce Momjian wrote: Please recompile with debug symbols and report back the stack trace. See the faq on running debug. No, I already did that (all my builds are like that anyway and I read stack traces more frequently than I'd like). The can't read pathname message I don't understand, but I had never seen it. -- Alvaro Herrera ([EMAIL PROTECTED]) La web junta la gente porque no importa que clase de mutante sexual seas, tienes millones de posibles parejas. Pon buscar gente que tengan sexo con ciervos incendiánse, y el computador dirá especifique el tipo de ciervo (Jason Alexander) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Current CVS tip segfaulting
On Fri, Apr 23, 2004 at 08:38:29PM -0400, Alvaro Herrera Munoz wrote: On Fri, Apr 23, 2004 at 07:00:05PM -0400, Bruce Momjian wrote: Please recompile with debug symbols and report back the stack trace. See the faq on running debug. No, I already did that (all my builds are like that anyway and I read stack traces more frequently than I'd like). The can't read pathname message I don't understand, but I had never seen it. strace'ing the postmaster suggested me that the dbname string in utils/init/postinit.c, the InitPostgres function, is the culprit. In fact, if I apply the following patch to tcop/postgres.c the whole thing stops happening. I don't know if this is the correct fix, but it may suggest something. Maybe it's a problem with my platform's argv handling (Mandrakelinux 10, kernel 2.6.3, glibc 2.3.3). Index: postgres.c === RCS file: /home/alvherre/cvs/pgsql-server/src/backend/tcop/postgres.c,v retrieving revision 1.400 diff -c -r1.400 postgres.c *** postgres.c 19 Apr 2004 17:42:58 - 1.400 --- postgres.c 24 Apr 2004 02:20:47 - *** *** 2686,2692 errhint(Try \%s --help\ for more information., argv[0]))); } else if (argc - optind == 1) ! dbname = argv[optind]; else if ((dbname = username) == NULL) { ereport(FATAL, --- 2648,2654 errhint(Try \%s --help\ for more information., argv[0]))); } else if (argc - optind == 1) ! dbname = pstrdup(argv[optind]); else if ((dbname = username) == NULL) { ereport(FATAL, -- Alvaro Herrera ([EMAIL PROTECTED]) Et put se mouve (Galileo Galilei) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Current CVS tip segfaulting
Alvaro Herrera [EMAIL PROTECTED] writes: In current (as of a couple hours ago) clean CVS tip sources, without any of my local changes, I'm getting a postmaster segfault when trying to connect to a non existant database. Hmm, works for me with this morning's sources. Bruce created a bug of that ilk a few days ago but fixed it shortly thereafter. Is it possible the anon-CVS server is out of date? regards, tom lane ---(end of broadcast)--- TIP 3: 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] Current CVS tip segfaulting
Alvaro Herrera Munoz wrote: On Fri, Apr 23, 2004 at 07:00:05PM -0400, Bruce Momjian wrote: Please recompile with debug symbols and report back the stack trace. See the faq on running debug. No, I already did that (all my builds are like that anyway and I read stack traces more frequently than I'd like). The can't read pathname message I don't understand, but I had never seen it. Oh, you mean the line: warning: current_sos: Can't read pathname for load map: Input/output error That is strange. Does it happen if you call abort() from the C code? That should dump a core on its own. The question is whether things are getting corrupted because of the way it crashed or some other configure problem. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Current CVS tip segfaulting
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: In current (as of a couple hours ago) clean CVS tip sources, without any of my local changes, I'm getting a postmaster segfault when trying to connect to a non existant database. Hmm, works for me with this morning's sources. Bruce created a bug of that ilk a few days ago but fixed it shortly thereafter. Is it possible the anon-CVS server is out of date? The bug I fixed was related to a postmaster restart when connecting to a non-existant database, and the fix was to prevent the longjump for elog(FATAL) if the code hadn't reached the longjump location yet. It could be a bug, but if it is, it is a different fix than the one I did, I think. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Current CVS tip segfaulting
FYI, I just tried: $ psql lkjasdf psql: FATAL: database lkjasdf does not exist (2) cat /u/pg/server.log LOG: database system was shut down at 2004-04-23 15:23:20 EDT LOG: checkpoint record is at 0/9D LOG: redo record is at 0/9D; undo record is at 0/0; shutdown TRUE LOG: next transaction ID: 457; next OID: 17208 LOG: database system is ready FATAL: database lkjasdf does not exist That looks OK to me on BSD/OS. I can put a copy of CVS head on my ftp site for testing if you wish. --- Alvaro Herrera Munoz wrote: On Fri, Apr 23, 2004 at 08:38:29PM -0400, Alvaro Herrera Munoz wrote: On Fri, Apr 23, 2004 at 07:00:05PM -0400, Bruce Momjian wrote: Please recompile with debug symbols and report back the stack trace. See the faq on running debug. No, I already did that (all my builds are like that anyway and I read stack traces more frequently than I'd like). The can't read pathname message I don't understand, but I had never seen it. strace'ing the postmaster suggested me that the dbname string in utils/init/postinit.c, the InitPostgres function, is the culprit. In fact, if I apply the following patch to tcop/postgres.c the whole thing stops happening. I don't know if this is the correct fix, but it may suggest something. Maybe it's a problem with my platform's argv handling (Mandrakelinux 10, kernel 2.6.3, glibc 2.3.3). Index: postgres.c === RCS file: /home/alvherre/cvs/pgsql-server/src/backend/tcop/postgres.c,v retrieving revision 1.400 diff -c -r1.400 postgres.c *** postgres.c 19 Apr 2004 17:42:58 - 1.400 --- postgres.c 24 Apr 2004 02:20:47 - *** *** 2686,2692 errhint(Try \%s --help\ for more information., argv[0]))); } else if (argc - optind == 1) ! dbname = argv[optind]; else if ((dbname = username) == NULL) { ereport(FATAL, --- 2648,2654 errhint(Try \%s --help\ for more information., argv[0]))); } else if (argc - optind == 1) ! dbname = pstrdup(argv[optind]); else if ((dbname = username) == NULL) { ereport(FATAL, -- Alvaro Herrera ([EMAIL PROTECTED]) Et put se mouve (Galileo Galilei) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
On Thu, 22 Apr 2004 [EMAIL PROTECTED] wrote: Download - Mirrors - Lists - Users - Developers - Docs - Search We could have: Download - Docs - Lists - Search - Community - Contrib Download would be a unified version of the Download/Mirrors links on the current site. I don't agree with this, since mirrors are web mirrors ... but I do like the 'Contrib' pointing to gborg/projects ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] The case for preserving case.
Hello, postgresql hackers. I am working with a client with a 20k record MySQL database (that will shortly expand to 100k/1m) and a few thousand lines of PHP code that does a lot of DB interaction. Their application, with a lot of relationships between data and a bunch of data integrity requirements is perfectly suited to postgresql. The PHP code follows a coding standard wherein variables are assigned CamelCase identifiers. All of the objects persist themselves to the DB, with a variable per column; on object initialization db columns are read from the db and added as attributes of the object. All of this breaks when I start to use postgresql, because all of the attributes become lowercased. Fixing this problem involves one of three things: 1.) rewriting all the code to have lowercased identifiers. This is effectively renaming everything, as long camel case attributes become much harder to read when they're lowercased. This also changes the clients' preferred coding standard. 2.) using double quotes around all identifiers in sql statements. As you're probably aware, there's no string format in PHP that lets you write double quote marks unescaped (and do variable substitution), so this involves rewriting hundreds of lines and imposing ongoing overhead for every SQL query. 3.) escaping 4 lines in src/backend/parser/scansup.c , where identifiers are lowercased. I understand that the reason for lowercasing is because odbc connections, etc expect case insensitivity, but the current behaviour isn't an SQL standard nor is it really case insensitivity. I would love case insensitivity with case preservation, but since that evidently is a more complicated option, I would like to know how I can formulate the 'case preserving' option in a way to make it palatable for inclusion. -- nothing can happen inside a sphere that you could not inscribe upon it. ~mindlacehttp://mindlace.net ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Stephan Szabo [EMAIL PROTECTED] writes: To clarify, I'm thinking about things where an application had gotten a quoted name and is now trying to use it where the object's canonical name was changed due to quoting changes. This only happens when quoting is inconsistently applied, but that's most of the problem. Actually, that's *all* the problem, at least as far as SQL commands are concerned. If you are consistent about always quoting or never quoting a particular name, you can't tell the difference between PG's behavior and SQL-spec behavior. Aside from the reality that apps aren't very consistent about their quoting behavior, the fly in this ointment is that whenever you query the database catalogs you will see the stored spelling of the name. So apps that rely on seeing the same spelling in the catalog that they entered could break. (In practice this doesn't seem to be as big a problem as the sloppy-quoting-behavior issue, though.) Personally I don't think that this is a transitional issue and we will someday all be happy in upper-case-only-land. Upper-case-only sucks, by every known measure of readability, and I don't want to have to put up with a database that forces that 1960s-vintage-hardware mindset on me. So what I'm holding out for is a design that lets me continue to see the current behavior if I set a GUC variable that says that's what I want. This seems possible (not easy, but possible) if we are willing to require the choice to be made at compile time ... but that sounds too restrictive to satisfy anybody ... what we need is a design that supports such a choice per-session, and I dunno how to do that. regards, tom lane PS: I resisted the temptation to SET THIS MESSAGE IN ALL UPPER CASE to make the point about readability. But if you want to argue the point with me, I'll be happy to do that for the rest of the thread. ---(end of broadcast)--- TIP 3: 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] Current CVS tip segfaulting
Bruce Momjian [EMAIL PROTECTED] writes: It could be a bug, but if it is, it is a different fix than the one I did, I think. Re-reading Alvaro's message, I wondered if cranking logging up to a higher-than-default setting was needed to reproduce the bug. A quick experiment in that line didn't show a problem, but maybe I missed the critical setting. Alvaro, what postgresql.conf settings are you using? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Sat, 24 Apr 2004, Tom Lane wrote: Upper-case-only sucks, by every known measure of readability, and I don't want to have to put up with a database that forces that 1960s-vintage-hardware mindset on me. Well, get used to it :-) So what I'm holding out for is a design that lets me continue to see the current behavior if I set a GUC variable that says that's what I want. Wouldn't the upper case identifiers just be visible in the \d output, table headers and such. You could still have psql tab completion produce lower case identifiers (if told using some setting). Even if the database store all non quoted names as upper case I would still use lower case in all applications and on the psql command line. It's not a big problem for me if the output of \d and the table headers and such is in upper case. One would get used to it fase. And maybe one can even store an extra bit telling if the string was created with or without quotes and have psql lower case all the ones created without quotes. First I thought that one can store the string with case all the time, and just convert when needed (when comparing identifiers). Perhaps using the non existant locale support and locales such as SQL_UPPER or SQL_MIXED. But it wont work since it would make Foo and Foo clash. When translated directly it would create separate entries Foo and FOO. ps. And if you want to play the WRITE MAILS USING ONLY UPPER CASE, BE MY GUEST! -- /Dennis Björklund ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Marc G. Fournier [EMAIL PROTECTED] writes: I don't agree with this, since mirrors are web mirrors ... but I do like the 'Contrib' pointing to gborg/projects ... Yeah, I like the contrib link idea too. Much of the recent discussion comes down to gborg not being visible enough. However ... how do we handle things once pgfoundry is online too? (I suppose two links labeled Old Contrib and New Contrib might serve as a forcing function to get projects to migrate over ;-)) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Current CVS tip segfaulting
Alvaro Herrera Munoz [EMAIL PROTECTED] writes: [ bug goes away if ] ! dbname = argv[optind]; [becomes] ! dbname = pstrdup(argv[optind]); Hm, that's interesting. I could believe this would have something to do with overwriting the argv area, but we have not touched any of that code recently; so why would it break for you just now? Which PS_USE_FOO option does your platform use? (See src/backend/utils/misc/ps_status.c) regards, tom lane ---(end of broadcast)--- TIP 3: 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
[HACKERS] Do we prefer software that works or software that looks good?
Tom Lane wrote: Personally I don't think that this is a transitional issue and we will someday all be happy in upper-case-only-land. Upper-case-only sucks, by every known measure of readability, and I don't want to have to put up with a database that forces that 1960s-vintage-hardware mindset on me. And I was feeling apologetic that I was accusing without a base the good (and I'm not cynical about that last adjective) people of the PostgreSQL of making life more difficult for programmers just because they don't like the asthetics of something which an external standard dictates. I mean, sure, I understand the sentiment. I don't like seeing all-caps either. But allow me to give an allegory from another free software project, one where I am an actual active code contributer. Imagine that Alexandre Juliard, the benevolent dictator for the Wine project, would have had the same attitude. Each time someone would come around saying today function X calls function Y, and this breaks program Z. We need to reverse X and Y, he would reply with But it makes more asthetic/program design/whatever sense to do it the way we do it today. The result would be that Wine would never come to the point where it can run Word, IE and other prominant Windows only applications. The reality of things is that Wine, just like Postgres, work by an external standard. Wine's standard is more strict, less documented, and more broad. However, like it or not, the more you deviate from the standard, the more you require people who want to use your technology to adapt to whatever it is that you do. This doesn't make sense on any level. So what I'm holding out for is a design that lets me continue to see the current behavior if I set a GUC variable that says that's what I want. This seems possible (not easy, but possible) if we are willing to require the choice to be made at compile time ... but that sounds too restrictive to satisfy anybody ... what we need is a design that supports such a choice per-session, and I dunno how to do that. In other words, you are going to reject the simpler solutions that treat this as a transition problem, because of asthetic issue? Not even program design issue, mind you. Sounds strange to me, and also pretty much guarentees that this will never happen. That would be a shame. The reason this would be a shame is because postgres is the same reason this thread was CCed to advocacy to begin with. Databases form a pretty saturated field. If Postgres is to break forward, it needs a niche. The fully-featured databases role is taken (Oracle), and the free database role is taken (MySQL). Postgres CAN take the fuly featured free database niche, but that will need help. The time is ripe, however. The company we're doing my current OLE DB work for has contacted me about this, and they dictated Postgres (MySQL was not nearly enough). They still want to see proof of concept working, but that's my job. However, I'm afraid they might give up if things become too complicated to port. Under such circumstances, every little help Postgres can give may mean the difference between breaking through and staying behind. I really wouldn't like to see such an important help break merely because Tom Lane doesn't like to see uppercase on his database tables list. Now, I'm intending to do the best I can on my end. This does have a pretty heavy cost. It means that the OLE DB driver will parse in details each query, and perform replacements on the query text. This is bug prone, difficult, hurts performance, and just plain wrong from a software design perspective. The current drift of wind, however, means that the PostgreSQL steering commite seems to prefer having a lesser quality driver to seeing ugly uppercase. regards, tom lane PS: I resisted the temptation to SET THIS MESSAGE IN ALL UPPER CASE to make the point about readability. But if you want to argue the point with me, I'll be happy to do that for the rest of the thread. Yes, it's a well known rhetoric technique. Take whatever argument your opponent say, and exagerate it to an absurd. Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Dennis Bjorklund [EMAIL PROTECTED] writes: On Sat, 24 Apr 2004, Tom Lane wrote: So what I'm holding out for is a design that lets me continue to see the current behavior if I set a GUC variable that says that's what I want. Wouldn't the upper case identifiers just be visible in the \d output, table headers and such. Exactly ... and that's where my readability complaint starts ... First I thought that one can store the string with case all the time, and just convert when needed (when comparing identifiers). People keep suggesting these random not-quite-standard behaviors, but I fail to see the point. Are you arguing for exact standards compliance, or not? If you're not, then you have to make your case on the claim that my nonstandard behavior is better than the existing nonstandard behavior. Which might be true, beauty being in the eye of the beholder, but I doubt you can prove it to the extent of overriding the backwards-compatibility issue. regards, tom lane ---(end of broadcast)--- TIP 3: 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: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Sat, 24 Apr 2004, Tom Lane wrote: First I thought that one can store the string with case all the time, and just convert when needed (when comparing identifiers). People keep suggesting these random not-quite-standard behaviors, but I fail to see the point. Are you arguing for exact standards compliance, or not? That was me making conversation, pointing out something that does not work. Since it does not work I don't want it to be implemented. And with work I mean not follow the standard. For something to follow standard it has to behave the correct way to the outside, how it's implemented is a different matter. The above does not work. Period. -- /Dennis Björklund ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org