[HACKERS] What's planned for 7.5?
Hi, Is this all that's planned for 7.5? (based on current TODO list) -Change factorial to return a numeric (Gavin) -COMMENT ON [ CAST | CONVERSION | OPERATOR CLASS | LARGE OBJECT | LANGUAGE ] (Christopher) -Have psql \dn show only visible temp schemas using current_schemas() -Have psql '\i ~/' actually load files it displays from home dir -Allow psql \du to show groups, and add \dg for groups -Allow pg_dump to dump CREATE CONVERSION (Christopher) -Use dependency information to dump data in proper order -Use background process to write dirty shared buffers to disk Thanks __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pljava revisited
--- Thomas Hallgren <[EMAIL PROTECTED]> wrote: > The JVM will be started on-demand. > Although I realize that one JVM per connection will consume a fair amount of > resources, I still think it is the best solution. The description of this > system must of course make it very clear that this is what happens and > ultimately provide the means of tuning the JVM's as much as possible. I think the new 1.5 JDK "Tiger" (to be released soon) will feature the "shared VM" option, i.e. one JVM could be used to run multiple and independent apps. Maybe worth looking into this. > I advocate this solution because I think that the people that has the > primary interest of a pl/java will be those who write enterprise systems > using Java. J2EE systems are always equipped with connection pools. IMHO, pl/java would be a great feature for Postgresql to have. It would increase pgSql's chances to be considered as an "enterprise" RDBMS since most of the enterprise apps are written in Java nowdays. Regards, __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ---(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] Max number of rows in a table
--- Tom Lane <[EMAIL PROTECTED]> wrote: > ow <[EMAIL PROTECTED]> writes: > > If I understand correctly, a table that has 4B+ rows cannot be restored > after > > the dump and that, in turn, may/will affect the ability to upgrade to new > > versions of pgSql. > > You don't understand correctly. I see. Thanks __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Max number of rows in a table
--- Tom Lane <[EMAIL PROTECTED]> wrote: > > Wouldn't the above put a limit on a number of records one could have > > in table? > > No. If I understand correctly, a table that has 4B+ rows cannot be restored after the dump and that, in turn, may/will affect the ability to upgrade to new versions of pgSql. This is somewhat similar to saying "yes" to the question "Can I drive this car at 55 mph?" and then forgetting to mention that the brakes will fail if the car reaches 55 mph. Thanks __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ---(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] Max number of rows in a table
> --- Tom Lane <[EMAIL PROTECTED]> wrote: > Actually you can only have 4 billion SQL commands per xid, because the > CommandId datatype is also just 32 bits. I've never heard of anyone > running into that limit, though. > Wouldn't the above put a limit on a number of records one could have in table? One have to use pg_dump/pg_restore to be able to upgrade between pgSql releases and/or to backup data. If one cannot backup data and/or upgrade between pg releases, then 4B records is the effective limit on the number of records in pgSql ... or am I missing something? Thanks __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] pg_restore with --disable-triggers
pg 7.4.0 Hi, >From the server log: Nov 28 16:31:02 srv postgres[2484]: [1076-7] ^I-- Disable triggers Nov 28 16:31:02 srv postgres[2484]: [1076-8] ^IUPDATE pg_catalog.pg_class SET reltriggers = 0 WHERE oid = 'test'::pg_catalog.regclass; If table with the name "test" exists in several schemas, wouldn't the above update disable triggers on table "test" in ALL schemas? Wwouldn't it also affect "test" table in the schema that is NOT being restored in a bad way? Thanks __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] pg_restore and create FK without verification check
--- Alvaro Herrera <[EMAIL PROTECTED]> wrote: > In what scenarios? I'd easily buy this if you are talking about small > tables. > Read the message again. __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_restore and create FK without verification check
--- Alvaro Herrera <[EMAIL PROTECTED]> wrote: > On Thu, Nov 27, 2003 at 12:40:28AM +0100, Andreas Pflug wrote: > > > A common mistake, can't count how often I created this one... And not > > easy to find, because EXPLAIN won't explain triggers. > > That's a pity. And the lack of EXPLAINing function execution, too. > Maybe it's not that hard to do? > I'd like to emphasize again that NOT having an index on the FK column is a perfectly valid approach, despite some opinions to the contrary. In fact, requiring an index on FK column(s) when it is not required by the application's logic IS a mistake since it slows down inserts/deletes/updates/vacume/reindex/etc on the respective table and wastes disk space (could be considerable amount on large tables). Also, FK column index DOES NOT, in general, solve performance issues with FK verification check. Someone may (and, I'm sure, will) simply have more data or more constraints. The only solution here appears to be the "--disable-triggers" option as it was suggested by Robert Treat. If it works then I'm fine, somehow I did not see that option in the beginning. Thanks __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ---(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] pg_restore and create FK without verification check
--- Andreas Pflug <[EMAIL PROTECTED]> wrote: > Stephan Szabo wrote: > > > > > > >IIRC, he was. I think the thing causing the difference between his times > >and the ones we saw typically when doing the tests was that he didn't have > >an index on the fktable's referencing column. > > > > > > A common mistake, can't count how often I created this one... Wrong. It's a mistake to think that you always HAVE to have an index on FK column. See the links below for more details: http://archives.postgresql.org/pgsql-admin/2003-11/msg00317.php http://archives.postgresql.org/pgsql-admin/2003-11/msg00319.php __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ---(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] pg_restore and create FK without verification check
--- Tom Lane <[EMAIL PROTECTED]> wrote: > Quite honestly, I think they should check their foreign keys. Generally speaking, I agree. The problem is that verification of FK constraint(s) may take too long, depending on the size of the db and other conditions. In my case, on test data, it takes about 1 hour to create tables and copy the data, then about 40 min to create indexes, then 4.5 hours to create one (1) FK constraint. In production, we'll have 10-100x more data than we have for testing. If we have a problem in production, the time necessary to restore the db is simply going to kill us. > People might be more interested in debating this topic with you if we > hadn't discussed it at length just a couple months back. There wasn't > consensus then that we had to offer an escape hatch, and you've not > offered any argument that wasn't made before. I'm simply presenting a problem for which I currently do not see any solution (it's very important for us to be able to restore db within a reasonable amount of time). If there's no solution and none is planned, then we cannot use pgsql, can we? Thanks __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ---(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] pg_restore and create FK without verification check
--- Tom Lane <[EMAIL PROTECTED]> wrote: > > This doesn't really replace pg_dump/pg_restore, because it probably > > wouldn't be able to upgrade a cluster. > > Right, any such physical dump would be limited to restoring a whole > cluster as-is: no imports into other clusters, no selectivity, no fancy > games. The main reason is you'd have to dump and restore pg_clog along > with the data files. > But that would not help people who would HAVE to use pg_dump/pg_restore (e.g. to backup/restore a single schema), would it? Depending on the db size, etc., creation of FK constraint(s) may take many hours. How should this be handled then? Thanks __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ---(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] pg_restore and create FK without verification check
--- Andreas Pflug <[EMAIL PROTECTED]> wrote: > Yes, I mentioned it just a few days when discussing dependency in pg_dump. > This is somewhat complementary to WAL and PITR. I'm seeking for a fast > way to dump and restore a complete database, like physical file copy, > without shutting down the backend. I was thinking of a BACKUP command > that streams out the files including any indexes and non-vacuumed > tuples. A database recreated from that wouldn't be as clean as a > pg_dump/pg_restored database, but it would be up much faster, and there > wouldn't be any dependency problem. > This doesn't really replace pg_dump/pg_restore, because it probably > wouldn't be able to upgrade a cluster. Still, it would be helpful for > disaster recovery. > I think creating a FK without verification check is still needed, especially in case if: 1) original db is corrupted 2) during cluster upgrade 3) there's a need to BACKUP/RESTORE a *schema* instead of db. Thanks __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ---(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] pg_restore and create FK without verification check
--- ow <[EMAIL PROTECTED]> wrote: > IMHO, not only data need to loaded before FK constraints are created but also > there has got to be a feature to allow creation of an FK constraint WITHOUT > doing the verification that all loaded/existing records satisfy the FK > constraint. The ability to create a FK constraint without verification of > existing records should exist by itself (maybe only to superuser) and also as > an option in pg_restore. > > More details: > http://archives.postgresql.org/pgsql-admin/2003-11/msg00308.php > http://archives.postgresql.org/pgsql-admin/2003-11/msg00323.php > It appears there's not a lot of interest in discussing the possibility of FK constraint creation WITHOUT the verification check. How then should one handle the situation with pg_restore and large dbs where creation of FK constraint(s) may take hours? Thanks __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ---(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] Anyone working on pg_dump dependency ordering?
--- Tom Lane <[EMAIL PROTECTED]> wrote: > FK, primary, and unique constraints are already split out from the > CREATE TABLE for performance reasons. We could think about folding them > back in in a schema-only dump, but in a full dump I don't think it's > negotiable --- you really want to load the table data before you install > these constraints. IMHO, not only data need to loaded before FK constraints are created but also there has got to be a feature to allow creation of an FK constraint WITHOUT doing the verification that all loaded/existing records satisfy the FK constraint. The ability to create a FK constraint without verification of existing records should exist by itself (maybe only to superuser) and also as an option in pg_restore. More details: http://archives.postgresql.org/pgsql-admin/2003-11/msg00308.php http://archives.postgresql.org/pgsql-admin/2003-11/msg00323.php Thanks __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
--- Dann Corbit <[EMAIL PROTECTED]> wrote: > I have all of the above database systems installed on the Windows 2000 > machine I am typing this message from. > DB/2 7.1 > Oracle 8.1.7 and 9.2.0.5 > MySQL 4.0.12 > Sybase Adaptive Server 12.0 > Informix Dynamic Server 9.2 > (Also SapDB, Firebird server, SQL*Server, and several others that are > not running right now) I'd say your environment is somewhat unique. > A typical window-phobic. Not really. I simply think there are more pressing issues than win32 port. Peace __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
--- Rocco Altier <[EMAIL PROTECTED]> wrote: > On Tue, 18 Nov 2003, ow wrote: > > > Have *never* seen ppl running Oracle or Sybase on Windows. > > I can't speak for Oracle, but Sybase on Windows is definitely a real > thing. If you have to deal with developing for their iAnywhere product iAnywhere is a completely separate product and is *not* a port of Sybase ASE (core db server). IIRC, iAnywhere runs only on Windows, well, maybe they ported it to Linux by now. __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
--- Dann Corbit <[EMAIL PROTECTED]> wrote: > Which feature is requested more than that? Not sure how often features are requested and by whom. However, if you take a look at the TODO list, you'll find plenty of stuff more important than win32 port. > Of the following (which includes every significant DBMS in terms of > market share), which did not consider a native Windows port to be > important: > SQL*Sever (all right, we can discount this one...) > DB/2 > Oracle > MySQL > Sybase > Informix Have *never* seen ppl running Oracle or Sybase on Windows. Not sure about DB/2 or Informix, never worked with them, but I'd suspect the picture is the same. They may claim that they have win port but it's more of a marketing gimmick than a useful feature that affects real, not hypothetical, users. IMHO, core postgreSql development should not be sacrificed for the sake of win32 port. __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
--- Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote: > > I don't call porting Postgres to run well on something like 40% of the > world's servers (or whatever it is) "just another port". Statistics is a tricky thing. IMHO, there are plenty of things that are much more important than win32 port. __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ---(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 do you want me to do?
> > http://www.atlassian.com/software/jira/pricing.jsp Another option is free open source Scarab, http://scarab.tigris.org Actually, I'd prefer it. __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two weeks to feature freeze
--- Dann Corbit <[EMAIL PROTECTED]> wrote: > Why couldn't you just release the win32 version of 7.4 > when it was finished. I agree. Don't delay *nix release because of win32 port is not ready. To many users win32 port is of marginal importance anyway. __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] No more RH7.3 RPMs?
RH7.3 is a supported distribution for at least 6 months. Any plans to add Postgres 7.3.3 RPMs for RH7.3? Thanks __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ---(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] Case insensitivity, and option?
> select * from table where field ILIKE 'blAH'; -- ;-)
> is almost as easy :-)
> PS: no, don't do this if you want portability. I think the charset
> idea's a better one.
>
> Ron
select * from table where lower(field)=lower('BLah') will break
portability too in the sense that many DBs (perhaps all commercial
ones) do not support functional indexes. Hence
lower(field)=lower('BLah') query will not be using index when it runs
on those DBs.
Besides, the developer must always remember to use conversion when
writing queries. This does not sound bad initially but in a big
application with many developers and complex query logic this will
create quite a few annoying, time consuming and difficult to find bugs.
Case insensitive charset definitely sounds like a better idea. Has
anyone done this yet? IMHO, this should be a part of core distribution
since 99.99% of queries do not need case sensitivity.
Thanks
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] PostgreSQL Benchmarks
There's "The Open Source Database Benchmark", http://osdb.sourceforge.net/. Anyone tried to use it? __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Windows Build System - who cares?
IMHO, replication, performance improvements, cross-db queries, etc is much better use of time than Windows port. --- Dann Corbit <[EMAIL PROTECTED]> wrote: > For MySQL: > There is no Cygwin needed. Period. > __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ---(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] 7.4 Wishlist
Cross-db queries. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
