Re: [GENERAL] Why PostgreSQL is not that popular as MySQL?
Bruce Momjian wrote: > > > The bottom line is that the marketing of PostgreSQL is not even close to > > that of MySQL. Thank god the code, community and support doesn't follow > > suit! > > I think MySQL got a big start by migrating mSQL users years ago and > having a compatibility module for mSQL. One great advantage of mySQL (and mSQL) ist the low connection-overhead. Especially in mSQL this was an explicit design-goal. In CGI-based WEB-environments it is very important that the time spent for connecting the database is as low as possible. Time wasted there cannot be autweight by fast SELECTS since many CGI do only very few SQL-statements. Using later WEB-techniques (as e.g. Servlets or Fast-CGI) this part becomes less important since an single DB-connection can be kept open across multiple WWW-requests. In applications where the connection is kept open for a long time the connection overhead becomes insignificant. Elmar
Re: [GENERAL] Can PostGreSQL handle 100 user database - more info
[EMAIL PROTECTED] wrote: > > I am not sure what an ole db provider is? This must be another method of > talking to the server from a client application. What advantages does it have? If you intend to use ADO you need an OLE-DB provider. > I have the open source ODBC client (and I know a Java version exists), it seems > ok but I don't know if it handles things like transactions and other advanced > functions. The ODBC midht cause some "interesting" trouble since VisualBasic tends to open multiple connections to the Server. This has tow disadvantages: 1. While using transaction isolation (not reading uncommitted data) you cannot read the data written on one connection over another one. If this does happen you might not immediately notive the rubbish happening. 2. With 100 users it might significant if there are 500 simultaneous connections open. At leas you have to raise the connection-limit. Elmar
Re: [GENERAL] 7.1 Release Date
Trond Eivind Glomsrød wrote: > No, it's not - it's just not making assumptions like "enough space is > present to dump everything somewhere" (if you have a multiGB database, > dumping it to upgrade sounds like a bad idea), "the database server is > running, so I can just dump the data" etc. On every big Database-Server there sould be a way do dump the data, the compressed dump is ways samaller than the files used by the database. If it is impossible to dump it to disk yopu can dump it to tape. If you cannot dump your data anywere you should simulate a disk-crash and restart with an empty database :-) Elmar
[GENERAL] sequences and Transactions
Hi! how can I setup sequences to have the current-value reset in case of an Transaction rollback. My intension is to get an contignous numbering of the rows. Currently in case of an Rollback one number is skipped since the record itself is not inserted but the counter is not reset. Elmar
Re: [GENERAL] database corruption?
Chris Jones schrieb: > I'm currently getting this error on my nightly vacuum. These two > indices (as you may have guessed already) are on columns named > interface and ewhen, on a table named error. The error table is > constantly being updated. (No comments about the implications of > that, please.) > > NOTICE: Index error_interface_idx: NUMBER OF INDEX' TUPLES (226766) IS NOT THE SAME >AS HEAP' (226765) > NOTICE: Index error_ewhen_idx: NUMBER OF INDEX' TUPLES (226766) IS NOT THE SAME AS >HEAP' (226765) > NOTICE: Index error_interface_idx: NUMBER OF INDEX' TUPLES (226766) IS NOT THE SAME >AS HEAP' (226765) > NOTICE: Index error_ewhen_idx: NUMBER OF INDEX' TUPLES (226766) IS NOT THE SAME AS >HEAP' (226765) The Index does not contain tuples having NULL in the indexed field. You should check if you have an tuple containing NULL in your table. If so remove or change the tuple or ignore the message. Elmar
[GENERAL] Migrating from DAO 2.5 to PostgreSQL
Hello, I intend to migrate an VB-4 application using the DAO 2.5-Access database to the PostgreSQL server. Is there an simple way to do so? I did try to yust move the Tables to the Server and link them back into an MDB file. This works in most cases but it is not efficient since the DAO engine processes complex queries locally. Any Hints? Elmar
