Re: [GENERAL] Is PostgreSQL an easy choice for a large CMS?
The open source offerings of ingres, ingres R3, runs the Wire section of our business http://www.onesteel.com Allan > > Postgres than from MySQL. I am financing this myself. hence the > > apprehension about the cost. Is there another contender I > > should think > > about. The material contained in this email may be confidential, privileged or copyrighted. If you are not the intended recipient, use, disclosure or copying of this information is prohibited. If you have received this document in error, please advise the sender and delete the document. Neither OneSteel nor the sender accept responsibility for any viruses contained in this email or any attachments. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Is PostgreSQL an easy choice for a large CMS?
Oops! [EMAIL PROTECTED] ("Tony Lausin") was seen spray-painting on a wall:
> Ahh. I see the point more clearly now. Perhaps the best strategy for
> me is to press on with Postgres until the project is at a profitable
> enough stage to merit a migration to Oracle - should Postgres become
> an issue. I feel more confident about being able to migrate from
> Postgres than from MySQL. I am financing this myself. hence the
> apprehension about the cost. Is there another contender I should think
> about.
The other plausible option as a "possibly inexpensive" alternative to
PostgreSQL or MySQL(tm) is Firebird, which used to be Borland
Interbase...
They lost a couple of developers to MySQL AB, which may present some
problems, eventually...
--
output = reverse("ofni.secnanifxunil" "@" "enworbbc")
http://linuxfinances.info/info/wp.html
"Tooltips are the proof that icons don't work."
-- Stefaan A. Eeckels
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Is PostgreSQL an easy choice for a large CMS?
Ahh. I see the point more clearly now. Perhaps the best strategy for me is to press on with Postgres until the project is at a profitable enough stage to merit a migration to Oracle - should Postgres become an issue. I feel more confident about being able to migrate from Postgres than from MySQL. I am financing this myself. hence the apprehension about the cost. Is there another contender I should think about. On 4/30/06, Matthew T. O'Connor wrote: Tony Lausin wrote: >> [ rotfl... ] MySQL will fall over under any heavy concurrent-write >> scenario. It's conceivable that PG won't do what you need either, >> but if not I'm afraid you're going to be forced into Oracle or one >> of the other serious-money DBs. >> > That's a scary idea - being forced into Oracle or Sybase. Isn't > Slashdot.org still running strongly off of MySQL? Yes Slashdot runs MySQL, however what Tom said was that MySQL will fall over under any heavy *concurrent-write* scenario. Concurrent-write is the operative word in that sentence. Slashdot by it's very nature reads from the database far far more than it writes. The only writes to the database are things like a new story and user submitted comments, both of with are small in comparison to the number of reads from the database. Matt ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[GENERAL] PG_RETURN_?
Hi, I have a set of functions for a data type that return small integers (i.e. [0..12]). I can, of course, represent it as a char, short or long (CHAR, INT16 or INT32). re there any advantages/drawbacks to chosing one particular PG_RETURN_ type over another (realizing that they are effectively just casts)? Thanks! --don ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] pg_dump warings
In article <[EMAIL PROTECTED]>, Devrim GUNDUZ <[EMAIL PROTECTED]> wrote: >Create the user again with the same userid (I mean revert what you did). >You can get this info from pg_tables and pg_authid(or pg_shadow, >depending on your PostgreSQL version). It turned out to be some tables had been created that shouldn't have been and the user that created them had been deleted. So the cure was deleting the tables. Thank you very much. You provided just the clues I needed. -- http://yosemitenews.info/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] pg_dump warings
Hi, On Sun, 2006-04-30 at 21:42 +, Rick Ellis wrote: > I did something foolish and now I'm getting warnings every time > pg_dump runs (hourly from cron). Anybody have a suggestion on how > to fix this? Create the user again with the same userid (I mean revert what you did). You can get this info from pg_tables and pg_authid(or pg_shadow, depending on your PostgreSQL version). Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
[GENERAL] Nested Query OK in psql but not in PHP
I have a nested query that runs fine in psql but does not return tabular data in PHP. I have built the query a step at a time and it works as expected, even in PHP up to the point where I include the second query, which uses a concatted string of field data to provide row identity. I'm quite the PHP newbie in mysql and even moreso with postgresql. Is there something that changes in the PHP code that builds the tabular display if a query is a nested query as opposed to it not being a nested query? I get no errors in /var/log/messages so _something_ thinks the query is OK. I'm just not seeing a populated table; only the html-coded column headings. I can include some actual cut-'n-paste, but I'd like to try and figure at least some of this out myself first. Regards, r ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[GENERAL] pg_dump warings
I did something foolish and now I'm getting warnings every time pg_dump runs (hourly from cron). Anybody have a suggestion on how to fix this? pg_dump: WARNING: owner of data type "accountuser" appears to be invalid pg_dump: WARNING: owner of data type "adminuser" appears to be invalid pg_dump: WARNING: owner of data type "alias" appears to be invalid pg_dump: WARNING: owner of data type "domain" appears to be invalid pg_dump: WARNING: owner of data type "domainadmin" appears to be invalid pg_dump: WARNING: owner of data type "search" appears to be invalid pg_dump: WARNING: owner of data type "pg_toast_41251" appears to be invalid pg_dump: WARNING: owner of data type "virtual" appears to be invalid pg_dump: WARNING: owner of data type "log_id_seq" appears to be invalid pg_dump: WARNING: owner of data type "log" appears to be invalid pg_dump: WARNING: owner of data type "pg_toast_41268" appears to be invalid pg_dump: WARNING: owner of table "accountuser" appears to be invalid pg_dump: WARNING: owner of table "adminuser" appears to be invalid pg_dump: WARNING: owner of table "alias" appears to be invalid pg_dump: WARNING: owner of table "domain" appears to be invalid pg_dump: WARNING: owner of table "domainadmin" appears to be invalid pg_dump: WARNING: owner of table "search" appears to be invalid pg_dump: WARNING: owner of table "virtual" appears to be invalid pg_dump: WARNING: owner of table "log_id_seq" appears to be invalid pg_dump: WARNING: owner of table "log" appears to be invalid -- http://yosemitecampsites.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Is PostgreSQL an easy choice for a large CMS?
On Apr 30, 2006, at 12:23 PM, Tony Lausin wrote: On the other hand, if you don't need multilang support, you'll find that postgresql is generally great to program and use. Tomislav Hello Tomislav, In my case, UTF-8 is a must. The site contextually will be directed to North Americans, although I do anticipate that many users will from time to time insert text in their own native languages. I myself certainly may use non-latin characters from time to time (cyrillic), so I find UTF-8 to be the best common bridge. Regards, Anthony Agreed, UTF-8 works fairly well. We just launched a site that has translated content for ~20 languages using a programming language that doesn't natively support unicode (Ruby... but jcode helps us out) and it works great. This is all running on PostgreSQL and we haven't seen any hiccups or complaints from people about strings not displaying right. I don't see why PostgreSQL wouldn't work for what you're working on... -Robby Robby Russell Founder & Executive Director PLANET ARGON, LLC Ruby on Rails Development, Consulting & Hosting www.planetargon.com www.robbyonrails.com +1 503 445 2457 +1 877 55 ARGON [toll free] +1 815 642 4968 [fax] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Is PostgreSQL an easy choice for a large CMS?
Tony Lausin wrote: [ rotfl... ] MySQL will fall over under any heavy concurrent-write scenario. It's conceivable that PG won't do what you need either, but if not I'm afraid you're going to be forced into Oracle or one of the other serious-money DBs. That's a scary idea - being forced into Oracle or Sybase. Isn't Slashdot.org still running strongly off of MySQL? Yes Slashdot runs MySQL, however what Tom said was that MySQL will fall over under any heavy *concurrent-write* scenario. Concurrent-write is the operative word in that sentence. Slashdot by it's very nature reads from the database far far more than it writes. The only writes to the database are things like a new story and user submitted comments, both of with are small in comparison to the number of reads from the database. Matt ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Is PostgreSQL an easy choice for a large CMS?
In my opinion, postgresql is not the way to go when building a cMS simply because of the way it handles strings. A CMS should be language/region agnostic i.e. supporting any chosen locale subset, rather then just one locale, as postgresql does. You can throw UTF-8 at the problem and it will enable data storage/retrieval, but you'll still be stuck with incorrect text ordering/sorting in any locale but the default. Truth be told, I don't know of a single RDBMS which handles this issue gracefully, but with postgresql, your basically stuck with a single language/locale. On the other hand, if you don't need multilang support, you'll find that postgresql is generally great to program and use. Tomislav Hello Tomislav, In my case, UTF-8 is a must. The site contextually will be directed to North Americans, although I do anticipate that many users will from time to time insert text in their own native languages. I myself certainly may use non-latin characters from time to time (cyrillic), so I find UTF-8 to be the best common bridge. Regards, Anthony ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Is PostgreSQL an easy choice for a large CMS?
Very odd. I had always heard that MySql (at least originally) was a "quick and dirty" database, easy to use, not fully standards compliant, and not enterprise grade. Postgresql on the other hand was always the heavyweight, standards compliant, enterprise db, which was more difficult to use and set up but much more resilient. Postgresql has been getting more UI support (often seen as a user friendly bonus) and things like autovacuum support so that it is easier to use out of the box, and MySql has been gaining standards compliance and resilience. Funny how perceptions can differ. Hi David, I think it's very odd too, cause that's the exact same perception of MySQL I have. My experience with MySQL is really limited to my Wordpress blog, and that means I've never actually designed a database with it. I wonder how much of this is just marketing and hype - either on the side of MySQL or the side of Oracle. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Is PostgreSQL an easy choice for a large CMS?
[ rotfl... ] MySQL will fall over under any heavy concurrent-write scenario. It's conceivable that PG won't do what you need either, but if not I'm afraid you're going to be forced into Oracle or one of the other serious-money DBs. regards, tom lane Hi Tom, That's a scary idea - being forced into Oracle or Sybase. Isn't Slashdot.org still running strongly off of MySQL? Regards, Anthony ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Operator Class for Hash
"Jozsef Szalay" <[EMAIL PROTECTED]> writes: > Could someone please help me out with an example on how to define an > operator and operator class that supports hash joins? Well, for starters, only the equality operator should be marked HASHES, and the support function for a hash opclass is completely different from the one for a btree opclass. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Is PostgreSQL an easy choice for a large CMS?
"Tony Lausin" <[EMAIL PROTECTED]> writes: > I'm working on a CMS which requires an open source database capable of > handling hundreds of thousands of users simultaneously, with a high > rate of database writes, and without buckling. We're talking somewhere > between nerve.com/catch27.com and xanga.com/friendster.com > PostgreSQL is a personal favorite of mine, and my gut instinct is that > it's the best choice for a large scale CMS serving many users; > however, I'm getting antsy. I keep getting suggestions that Postgres > is really only suited to small and medium projects, and that I should > be looking at MySQL for a large scale database drive site. [ rotfl... ] MySQL will fall over under any heavy concurrent-write scenario. It's conceivable that PG won't do what you need either, but if not I'm afraid you're going to be forced into Oracle or one of the other serious-money DBs. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Is PostgreSQL an easy choice for a large CMS?
On 4/30/06, Tony Lausin <[EMAIL PROTECTED]> wrote: Hello all, I'm working on a CMS which requires an open source database capable of handling hundreds of thousands of users simultaneously, with a high rate of database writes, and without buckling. We're talking somewhere between nerve.com/catch27.com and xanga.com/friendster.com In my opinion, postgresql is not the way to go when building a cMS simply because of the way it handles strings. A CMS should be language/region agnostic i.e. supporting any chosen locale subset, rather then just one locale, as postgresql does. You can throw UTF-8 at the problem and it will enable data storage/retrieval, but you'll still be stuck with incorrect text ordering/sorting in any locale but the default. Truth be told, I don't know of a single RDBMS which handles this issue gracefully, but with postgresql, your basically stuck with a single language/locale. On the other hand, if you don't need multilang support, you'll find that postgresql is generally great to program and use. Tomislav ---(end of broadcast)--- TIP 6: explain analyze is your friend
[GENERAL] Operator Class for Hash
Hi All, Could someone please help me out with an example on how to define an operator and operator class that supports hash joins? I’ve tried to follow the instructions in the documentation for v8.1 but I’m obviously doing something wrong, because the engine crashes on an operation that tries to use the operator. Here is what I have: CREATE OPERATOR < (leftarg = mytype, rightarg = mytype, procedure = mytype_lt, commutator = >, negator = >=, restrict = scalarltsel, join = scalarltjoinsel, HASHES); CREATE OPERATOR <= (leftarg = mytype, rightarg = mytype, procedure = mytype_le, commutator = >=, negator = >, restrict = scalarltsel, join = scalarltjoinsel, HASHES, sort1 = <, sort2 = <); CREATE OPERATOR = (leftarg = mytype, rightarg = mytype, procedure = mytype_eq, commutator = =, negator = <>, restrict = eqsel, join = eqjoinsel, HASHES, sort1 = <, sort2 = <); CREATE OPERATOR >= (leftarg = mytype, rightarg = mytype, procedure = mytype_ge, commutator = <=, negator = <, restrict = scalargtsel, join = scalargtjoinsel, HASHES, sort1 = <, sort2 = <); CREATE OPERATOR > (leftarg = mytype, rightarg = mytype, procedure = mytype_gt, commutator = <, negator = <=, restrict = scalargtsel, join = scalargtjoinsel, HASHES, sort1 = <, sort2 = <); CREATE OPERATOR <> (leftarg = mytype, rightarg = mytype, procedure = mytype_ne, commutator = <>, negator = =, restrict = neqsel, join = neqjoinsel, HASHES, sort1 = <, sort2 = <); CREATE OPERATOR CLASS mytype_ops DEFAULT FOR TYPE mytype USING btree AS OPERATOR 1 <, OPERATOR 2 <=, OPERATOR 3 =, OPERATOR 4 >=, OPERATOR 5 >, FUNCTION 1 mytype_comp(mytype, mytype); CREATE OPERATOR CLASS mytype_ops DEFAULT FOR TYPE mytype USING hash AS OPERATOR 1 =, FUNCTION 1 mytype_comp(mytype, mytype); Thank you for the help!
Re: [GENERAL] Is PostgreSQL an easy choice for a large CMS?
On 4/30/06, Tony Lausin <[EMAIL PROTECTED]> wrote: Hello all, I'm working on a CMS which requires an open source database capable of handling hundreds of thousands of users simultaneously, with a high rate of database writes, and without buckling. We're talking somewhere between nerve.com/catch27.com and xanga.com/friendster.com PostgreSQL is a personal favorite of mine, and my gut instinct is that it's the best choice for a large scale CMS serving many users; however, I'm getting antsy. I keep getting suggestions that Postgres is really only suited to small and medium projects, and that I should be looking at MySQL for a large scale database drive site. I'm not really a fan of MySQL, but I'll consider it if it truly is the better choice in this case. I just don't understand how it would be. I'm thinking this is solely in reference to VACUUM. Even with autovacuum suport, I tend to agree there is at least one handicap. I could really use some enlightenment on just where PostgreSQL fits in a single-server, highly-trafficked web site serving mostly text, pictures and possibly streaming media. http://people.planetpostgresql.org/xzilla/index.php?/archives/151-Sean-Chittenden-on-RubyOnRails-Podcast.html http://www.postgresql.org/about/casestudies/ http://www.postgresql.org/about/users are all good places to start. TBH it depends a lot on your data and how you structure it. I wrote a small tute on how to get rid of left-join type queries and use triggers to keep count(*) type queries to a minimum.. http://www.designmagick.com/article/36/Forum-Project/Database-Design-Issues It's not always possible, but there are ways to minimize count(*), min(field), max(field) type queries where postgresql isn't able to optimize fully due to mvcc issues. -- Postgresql & php tutorials http://www.designmagick.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Is PostgreSQL an easy choice for a large CMS?
On Sunday 30 April 2006 12:01, Tony Lausin wrote: > Hello all, > > I'm working on a CMS which requires an open source database capable of > handling hundreds of thousands of users simultaneously, with a high > rate of database writes, and without buckling. We're talking somewhere > between nerve.com/catch27.com and xanga.com/friendster.com > > PostgreSQL is a personal favorite of mine, and my gut instinct is that > it's the best choice for a large scale CMS serving many users; > however, I'm getting antsy. I keep getting suggestions that Postgres > is really only suited to small and medium projects, and that I should > be looking at MySQL for a large scale database drive site. I'm not > really a fan of MySQL, but I'll consider it if it truly is the better > choice in this case. I just don't understand how it would be. I'm > thinking this is solely in reference to VACUUM. Even with autovacuum > suport, I tend to agree there is at least one handicap. > > I could really use some enlightenment on just where PostgreSQL fits in > a single-server, highly-trafficked web site serving mostly text, > pictures and possibly streaming media. > > Regards, > > Anthony > Very odd. I had always heard that MySql (at least originally) was a "quick and dirty" database, easy to use, not fully standards compliant, and not enterprise grade. Postgresql on the other hand was always the heavyweight, standards compliant, enterprise db, which was more difficult to use and set up but much more resilient. Postgresql has been getting more UI support (often seen as a user friendly bonus) and things like autovacuum support so that it is easier to use out of the box, and MySql has been gaining standards compliance and resilience. Funny how perceptions can differ. David ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[GENERAL] Is PostgreSQL an easy choice for a large CMS?
Hello all, I'm working on a CMS which requires an open source database capable of handling hundreds of thousands of users simultaneously, with a high rate of database writes, and without buckling. We're talking somewhere between nerve.com/catch27.com and xanga.com/friendster.com PostgreSQL is a personal favorite of mine, and my gut instinct is that it's the best choice for a large scale CMS serving many users; however, I'm getting antsy. I keep getting suggestions that Postgres is really only suited to small and medium projects, and that I should be looking at MySQL for a large scale database drive site. I'm not really a fan of MySQL, but I'll consider it if it truly is the better choice in this case. I just don't understand how it would be. I'm thinking this is solely in reference to VACUUM. Even with autovacuum suport, I tend to agree there is at least one handicap. I could really use some enlightenment on just where PostgreSQL fits in a single-server, highly-trafficked web site serving mostly text, pictures and possibly streaming media. Regards, Anthony ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] how can i view deleted records?
On Sat, Apr 29, 2006 at 07:05:35PM -0700, Steve Atkins wrote: > >Just kidding... once you delete your records... they are gone. > > That's not true. > > Deleted (or modified) records don't go away until the space > they use is recycled by the VACUUM command. Well yes, but with autovacuum you don't know when that might be. > However, there's no support in postgresql for any sort of > "time travel", including viewing deleted tuples. The data > is there on the disk, but there is no clean way to view it > via the database. Well, there is a timetravel module which you can enable per table. Just showing deleted records in general doesn't work well because it violates all sorts of constraints. If you show deleted records, all of a sudden your unique indexes arn't unique anymore. Timetravel is expensive though, which is why it's not by default. Have a ncie day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
[GENERAL] Ответ: how can i view deleted records?
Thanks. I thought that there are some standard utilities or sql request in postgres to view deleted or modified tuples. 2006/4/30, Steve Atkins <[EMAIL PROTECTED]>: On Apr 29, 2006, at 4:18 PM, Robby Russell wrote: > > On Apr 29, 2006, at 12:49 PM, Dan Black wrote: > >> Hello, everybody! >> How can I view deleted records in table? > > SELECT * FROM recycle_bin; > > ;-) > > Just kidding... once you delete your records... they are gone. That's not true. Deleted (or modified) records don't go away until the space they use is recycled by the VACUUM command. However, there's no support in postgresql for any sort of "time travel", including viewing deleted tuples. The data is there on the disk, but there is no clean way to view it via the database. It's certainly not something a DBA should even think about (outside of security issues) but deleted tuples are available in a forensics situation, as long as vacuum hasn't been run. Cheers, Steve ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Verba volent, scripta manent Dan Black ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
