Re: [HACKERS] Call for 7.5 feature completion
FWIW, I think a lot of people didn't me too on all the features they want, so I wouldn't put too much weight on the ranking here... On Mon, Sep 05, 2005 at 05:43:16PM +0200, Peter Eisentraut wrote: Am Freitag, 26. August 2005 01:13 schrieb Alvaro Herrera: Or, slightly different, what are people's most wanted features? For entertainment, here is a summary the most requested features: 1. MERGE command 2. Table partitioning 2. Materialized views 2. Updatable views 5. Index-organized tables, index-only access 6. Recursive queries 6. Window functions 8. Debuggable PL/pgSQL 8. Better bulk load 8. Multimaster replication 8. Database assertions 8. Multi-threaded/process query execution 8. CUBE and ROLLUP 8. Concurrent vacuum So there is plenty of work left... -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
Oh, I remembered another of my personal feature requests for 8.2 :D * Fix planning and execution of set operations so that they're not tragically slow. eg. rewriting into outer joins, etc. Chris ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for 7.5 feature completion
Am Freitag, 26. August 2005 01:13 schrieb Alvaro Herrera: Or, slightly different, what are people's most wanted features? For entertainment, here is a summary the most requested features: 1. MERGE command 2. Table partitioning 2. Materialized views 2. Updatable views 5. Index-organized tables, index-only access 6. Recursive queries 6. Window functions 8. Debuggable PL/pgSQL 8. Better bulk load 8. Multimaster replication 8. Database assertions 8. Multi-threaded/process query execution 8. CUBE and ROLLUP 8. Concurrent vacuum So there is plenty of work left... -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
Merlin Moncure [EMAIL PROTECTED] wrote And I think VC++ 6.0 is ok, it is power enough and not so big for pgsql's development. And latter versions of VC++ can automatically convert 6.0's project files. There are also a VC++7 to VC++6 project converter on www.codeproject.com. | You might be surprised to know that this has been already done. Back in | the 7.2 cycle there was a win32 build floating around that compiled and | built inside of visual studio 6. I think Jan Wieck was one of the | people involved in the effort. | That would be a good place to start looking. | Merlin I know sth. about Jan Wieck's work, but cannot find the VC++ projects. Now I have started a PgFoundry project vcproject. Regards, William ZHANG The peerdirect port is still available on Bruce's ftp site here: ftp://momjian.postgresql.org/pub/postgresql/win32/PeerDirect/ as a patch vs. the 7.2 postgresql. fwiw, I think your project is in a race against time vs. the upcoming improved win32 posix support. Details are skimpy but the rumors are ms is going to allow running just about any unix app without emulation. I remember that Microsoft stopped supporting POSIX subsystem in Win32. Can you give me more information? Currently the major advantage I see of providing alternative to mingw is providing 64 bit version of postgresql to windows since mingw does not appear to be going 64 bit anytime soon. Not thinking about that yet. The win32 build environment issue was discussed quite heatedly when the porting effort started heating up. At the time I advocated for a vc6 build environment but have since then realized that probably would have been a mistake. Merlin ---(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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for 7.5 feature completion
Magnus Hagander wrote: Building with the VC compiler using GNU makefiles is a whole different story - if that can be made to work reasonably easily it would be a worthwhile goal The main problem is that the VC compiler uses completely different command-line options than a typical Unix compiler. I recall that there is a wrapper script out there, which would surely be a good starting point for someone investigating this. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for 7.5 feature completion
And I think VC++ 6.0 is ok, it is power enough and not so big for pgsql's development. And latter versions of VC++ can automatically convert 6.0's project files. There are also a VC++7 to VC++6 project converter on www.codeproject.com. | You might be surprised to know that this has been already done. Back in | the 7.2 cycle there was a win32 build floating around that compiled and | built inside of visual studio 6. I think Jan Wieck was one of the | people involved in the effort. | That would be a good place to start looking. | Merlin I know sth. about Jan Wieck's work, but cannot find the VC++ projects. Now I have started a PgFoundry project vcproject. Regards, William ZHANG The peerdirect port is still available on Bruce's ftp site here: ftp://momjian.postgresql.org/pub/postgresql/win32/PeerDirect/ as a patch vs. the 7.2 postgresql. fwiw, I think your project is in a race against time vs. the upcoming improved win32 posix support. Details are skimpy but the rumors are ms is going to allow running just about any unix app without emulation. Currently the major advantage I see of providing alternative to mingw is providing 64 bit version of postgresql to windows since mingw does not appear to be going 64 bit anytime soon. The win32 build environment issue was discussed quite heatedly when the porting effort started heating up. At the time I advocated for a vc6 build environment but have since then realized that probably would have been a mistake. Merlin ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Call for 7.5 feature completion
I think the most popular method to build a project on Win32 is using MSVC or Intel C. Intel C can be integrated with MSVC's IDE to help developers increase their productivity. Actually I have tried to make the backend of pgsql-8.0.3 build with MSVC 6.0, and it works well. Should I polish it and send it as a patch? Having been a Win32 developer for several years, I think it is more convenient to use MSVC's IDE than CL.exe with NMAKE.exe. Although I do not like Microsoft very much, and like to use MinGW or Cygwin to do some small tests, MSVC is more suitable for native Win32 development. If pgsql want to be the first class citizen on Windows, and want to compete with MySQL, I think supporting MSVC is important. I beleive there will be many contributions from the Win32 world. I think supporting MSVC is important, certainly (though I think that supporting the Intel compiler is even better, as the only compelling reason, IMO, to switch for the server end is generated code quality). But that's very different from supporting visual studio. I've been doing cross-platform development on a big codebase for years, and the idea of trying to use the proprietary build environments on each platform, and expecting to keep them sufficiently in-sync that the end result is actually comparable on each platform is laughable. And that's on a much smaller, simpler codebase than PG with a much smaller, more integrated development team. I use gmake or cons everywhere. On Windows I run them under cygwin and have them call the MSVC commandline compiler. It all works fine. And it doesn't stop me from using Visual Studio to edit the code, run the debugger or anything like that. On OS X I can use XCode. On Solaris I use the Forte environment. On Linux I use emacs and gcc. And that's all on the same codebase with the same makefile checked out from the same CVS repository. I think the main problem with switching to visual studio project files is maintainabilty. (It's not easy to get all the custom actions used to build some parts running in VS, but i'm su8re you can do it). The core development is done on Unix, and if you can't use the same Makefiles it's only a matter of time (and I bet very short time) before the VS files would be broken compared to the main ones etc. Win32 is a much more first class citizen now that it builds with gmake than it would be then. Building with the VC compiler using GNU makefiles is a whole different story - if that can be made to work reasonably easily it would be a worthwhile goal (in my experience, for example, the VSEE compiler optimises things a whole lot better than gcc on win32). I just don't see the payoff in getting rid of make. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Call for 7.5 feature completion
Magnus Hagander [EMAIL PROTECTED] writes: Building with the VC compiler using GNU makefiles is a whole different story - if that can be made to work reasonably easily it would be a worthwhile goal (in my experience, for example, the VSEE compiler optimises things a whole lot better than gcc on win32). I just don't see the payoff in getting rid of make. +1 here. It's already enough of a pain in the neck taking care of the Windows-specific build support for libpq and psql; we're not going to take on maintaining a complete parallel build infrastructure for a proprietary platform. (In fact, there's been serious discussion of dropping the Windows-specific build scripts that are there now, as it's not clear why they are still needed when you can build the stuff in mingw and then use it elsewhere.) But we already deal with lots of different compilers, so one more shouldn't be a problem --- as long as you can drive it with gmake. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
I think the main problem with switching to visual studio project files is maintainabilty. (It's not easy to get all I think the target should be a way to auto create those files with gmake (maybe with mingw for configure). The format of VS6 project and workspace files is pretty simple. It should be possible to derive them from the makefiles and simple templates. Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
William ZHANG wrote: - Original Message - From: Dave Page dpage@vale-housing.co.uk To: Andrew Dunstan [EMAIL PROTECTED]; William ZHANG [EMAIL PROTECTED] Cc: pgsql-hackers@postgresql.org Sent: Thursday, September 01, 2005 3:21 PM Subject: RE: [HACKERS] Call for 7.5 feature completion And even those are a royal pain to maintain, never mind an entire set. Besides, I'm sure what William really wants is not nmake files, but VC++ Project files - but then which version do we keep? It's not like we could say that everyone should be using VS2005, so all commits would have to be VC++ 6.0 or earlier compatible, otherwise someone is bound to complain. You are right. What I want is VC++ projects(*.dsp, *.dsw). Once the project files is created, the maintance work is simply add/remove some new/deleted source files (*.c only) from the dsps. And I think VC++ 6.0 is ok, it is power enough and not so big for pgsql's development. And latter versions of VC++ can automatically convert 6.0's project files. There are also a VC++7 to VC++6 project converter on www.codeproject.com. Also, how do you build the backend with VC without the MinGW compatibility routines and include files? I know everyone is focused on the build environment and shell script support, but there is also library code translation support in MinGW too that we use. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
-Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] Sent: 01 September 2005 03:31 To: William ZHANG Cc: Dave Page; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Call for 7.5 feature completion We currently have nmake files for the client libraries, And even those are a royal pain to maintain, never mind an entire set. Besides, I'm sure what William really wants is not nmake files, but VC++ Project files - but then which version do we keep? It's not like we could say that everyone should be using VS2005, so all commits would have to be VC++ 6.0 or earlier compatible, otherwise someone is bound to complain. I agree with Andrew though - maintaining VC++ project files or nmake files is just not practical - especially given that most of our developers are not Windows users. Regards, Dave. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Call for 7.5 feature completion
- Original Message - From: Dave Page dpage@vale-housing.co.uk To: Andrew Dunstan [EMAIL PROTECTED]; William ZHANG [EMAIL PROTECTED] Cc: pgsql-hackers@postgresql.org Sent: Thursday, September 01, 2005 3:21 PM Subject: RE: [HACKERS] Call for 7.5 feature completion And even those are a royal pain to maintain, never mind an entire set. Besides, I'm sure what William really wants is not nmake files, but VC++ Project files - but then which version do we keep? It's not like we could say that everyone should be using VS2005, so all commits would have to be VC++ 6.0 or earlier compatible, otherwise someone is bound to complain. You are right. What I want is VC++ projects(*.dsp, *.dsw). Once the project files is created, the maintance work is simply add/remove some new/deleted source files (*.c only) from the dsps. And I think VC++ 6.0 is ok, it is power enough and not so big for pgsql's development. And latter versions of VC++ can automatically convert 6.0's project files. There are also a VC++7 to VC++6 project converter on www.codeproject.com. I agree with Andrew though - maintaining VC++ project files or nmake files is just not practical - especially given that most of our developers are not Windows users. I am expecting more and more Windows users to join us. According to Andrew's advice, I will try to start a project on pgfoundry to provide the VC++ project files. Regards, Dave. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Call for 7.5 feature completion
- Original Message - From: Andrew Dunstan [EMAIL PROTECTED] To: Dave Page dpage@vale-housing.co.uk Cc: William ZHANG [EMAIL PROTECTED]; pgsql-hackers@postgresql.org Sent: Wednesday, August 31, 2005 10:24 PM Subject: Re: [HACKERS] Call for 7.5 feature completion Dave Page wrote: * Compile with MSVC on Win32 platforms. MySQL support it. So what? It would take a major amount of work, with no useful benefits. ... and you can compile all the client and library stuff with MSVC - just not the server nor extensions. But the audience for compiling those is far smaller. I think the most popular method to build a project on Win32 is using MSVC or Intel C. Intel C can be integrated with MSVC's IDE to help developers increase their productivity. Actually I have tried to make the backend of pgsql-8.0.3 build with MSVC 6.0, and it works well. Should I polish it and send it as a patch? Having been a Win32 developer for several years, I think it is more convenient to use MSVC's IDE than CL.exe with NMAKE.exe. Although I do not like Microsoft very much, and like to use MinGW or Cygwin to do some small tests, MSVC is more suitable for native Win32 development. If pgsql want to be the first class citizen on Windows, and want to compete with MySQL, I think supporting MSVC is important. I beleive there will be many contributions from the Win32 world. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
William wrote: You are right. What I want is VC++ projects(*.dsp, *.dsw). Once the project files is created, the maintance work is simply add/remove some new/deleted source files (*.c only) from the dsps. And I think VC++ 6.0 is ok, it is power enough and not so big for pgsql's development. And latter versions of VC++ can automatically convert 6.0's project files. There are also a VC++7 to VC++6 project converter on www.codeproject.com. You might be surprised to know that this has been already done. Back in the 7.2 cycle there was a win32 build floating around that compiled and built inside of visual studio 6. I think Jan Wieck was one of the people involved in the effort. That would be a good place to start looking. Merlin ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
On Thu, Sep 01, 2005 at 09:17:38AM +0800, William ZHANG wrote: Dave Page wrote: * Compile with MSVC on Win32 platforms. MySQL support it. So what? It would take a major amount of work, with no useful benefits. ... and you can compile all the client and library stuff with MSVC - just not the server nor extensions. But the audience for compiling those is far smaller. I think the most popular method to build a project on Win32 is using MSVC or Intel C. Intel C can be integrated with MSVC's IDE to help developers increase their productivity. Actually I have tried to make the backend of pgsql-8.0.3 build with MSVC 6.0, and it works well. Should I polish it and send it as a patch? Having been a Win32 developer for several years, I think it is more convenient to use MSVC's IDE than CL.exe with NMAKE.exe. Although I do not like Microsoft very much, and like to use MinGW or Cygwin to do some small tests, MSVC is more suitable for native Win32 development. If pgsql want to be the first class citizen on Windows, and want to compete with MySQL, I think supporting MSVC is important. I beleive there will be many contributions from the Win32 world. I think supporting MSVC is important, certainly (though I think that supporting the Intel compiler is even better, as the only compelling reason, IMO, to switch for the server end is generated code quality). But that's very different from supporting visual studio. I've been doing cross-platform development on a big codebase for years, and the idea of trying to use the proprietary build environments on each platform, and expecting to keep them sufficiently in-sync that the end result is actually comparable on each platform is laughable. And that's on a much smaller, simpler codebase than PG with a much smaller, more integrated development team. I use gmake or cons everywhere. On Windows I run them under cygwin and have them call the MSVC commandline compiler. It all works fine. And it doesn't stop me from using Visual Studio to edit the code, run the debugger or anything like that. On OS X I can use XCode. On Solaris I use the Forte environment. On Linux I use emacs and gcc. And that's all on the same codebase with the same makefile checked out from the same CVS repository. Cheers, Steve ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
On 8/26/05, Alvaro Herrera [EMAIL PROTECTED] wrote: Or, slightly different, what are people's most wanted features? One feature, or rather set of features which was missing from the list and I think it is important: i18n. :) I mean, PostgreSQL has a number of good features concerning internationalization, like UTF-8 support, transparent charset conversions, etc, but it also is area where new users are likely to get bit. One of the most gotcha-prone areas in PostgreSQL IMHO. If you stick with English, its OK. If you want different language, say Polish, German, whatever you'll probably careful enough to set a good locale. If you decide you want to make a hybrid Polish-German database -- you may run into problems, like indexes and ordering -- indexes are ordered using only one collation mechanism, so you should probably use C locale. If you're unlucky -- you have to recreate whole database. And then if you intend to use tsearch2, you have to set it up carefully for given needs. I'm not saying that mysqlish approach of setting collate per table would be a good solution. Frankly I don't think there is an ideal solution for this. Some time ago someone suggested using universal UTF-8 collation, which is good for most languages (and not for Turkish :)) -- I believe I've seen a patch for this on this list. Having some one size fits most solution could be helpful. Anyway, the i18n problem is a child-age illness, once you get over with it, you're most likely safe from it for the rest of your life. But some newbies may not get through it. ;) Regards, Dawid
Re: [HACKERS] Call for 7.5 feature completion
* Updatable Views per SQL * INTERVAL data type per SQL * BLOB/CLOB data type per SQL * Faster bulk load * Remove current transaction is aborted, commands ignored ... * Compile with MSVC on Win32 platforms. MySQL support it. * Thread safety libpq, ecpg. -- Regards, William ZHANG ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William ZHANG Sent: 31 August 2005 10:51 To: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Call for 7.5 feature completion * Faster bulk load Done, iirc. * Compile with MSVC on Win32 platforms. MySQL support it. So what? It would take a major amount of work, with no useful benefits. * Thread safety libpq, ecpg. Done. Regards, Dave. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
Dave Page wrote: * Compile with MSVC on Win32 platforms. MySQL support it. So what? It would take a major amount of work, with no useful benefits. ... and you can compile all the client and library stuff with MSVC - just not the server nor extensions. But the audience for compiling those is far smaller. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for 7.5 feature completion
William ZHANG wrote: - Original Message - From: Andrew Dunstan [EMAIL PROTECTED] To: Dave Page dpage@vale-housing.co.uk Cc: William ZHANG [EMAIL PROTECTED]; pgsql-hackers@postgresql.org Sent: Wednesday, August 31, 2005 10:24 PM Subject: Re: [HACKERS] Call for 7.5 feature completion Dave Page wrote: * Compile with MSVC on Win32 platforms. MySQL support it. So what? It would take a major amount of work, with no useful benefits. ... and you can compile all the client and library stuff with MSVC - just not the server nor extensions. But the audience for compiling those is far smaller. I think the most popular method to build a project on Win32 is using MSVC or Intel C. Intel C can be integrated with MSVC's IDE to help developers increase their productivity. Actually I have tried to make the backend of pgsql-8.0.3 build with MSVC 6.0, and it works well. Should I polish it and send it as a patch? Having been a Win32 developer for several years, I think it is more convenient to use MSVC's IDE than CL.exe with NMAKE.exe. Although I do not like Microsoft very much, and like to use MinGW or Cygwin to do some small tests, MSVC is more suitable for native Win32 development. If pgsql want to be the first class citizen on Windows, and want to compete with MySQL, I think supporting MSVC is important. I beleive there will be many contributions from the Win32 world. You are missing the point. We are not prepared to support two completely different build systems. Our build system is very very heavily dependent on gmake. So if you want to change the build system you have to come up with something that works everywhere. COming up with a project file or an nmake file for Windows is not hard. Keeping them in step with everything else is very hard. We currently have nmake files for the client libraries, but project files might be good to have too, and I don't think we have those. Why not start a pgfoundry project to publish some MSVC project files, at least for the client libs? cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
In article [EMAIL PROTECTED], Christopher Kings-Lynne [EMAIL PROTECTED] writes: * optional interface which sends a row typeoid along with each row in a result set Oh, and 'select rowid, * from table' which returns special rowid column that just incrementally numbers each row. Why? It's a thing best handled at the client side, and we already have a way to do it server-side (temporary sequences). ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for 7.5 feature completion
On 29 Aug 2005 09:56:44 +0200, Harald Fuchs wrote: Christopher Kings-Lynne writes: Oh, and 'select rowid, * from table' which returns special rowid column that just incrementally numbers each row. I think you can pretty much do that already by defining your own aggregate function. The obvious downside is that you need to put all the other columns in the GROUP BY clause. There might be some performance implications from the grouping, but I would presume that a rowid is most usefull in a situation where you are sorting anyway. I have to admit this part of the SQL spec is a bit over my head, but isn't grouping on an empty grouping set essentially a no-op? Implementing that would then take care of having to put all the coulmns in the GROUP BY clause. Why? Because, although rarely necessary, it is frequently convenient to have such functionality on the server. Jochem ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for 7.5 feature completion
On Mon, 29 Aug 2005, Christopher Kings-Lynne wrote: Oh, and 'select rowid, * from table' which returns special rowid column that just incrementally numbers each row. In sql2003 there is a window function called ROW_NUMBER() that can be used to get numbers like that (one also need to specify the window to be the full table in this case). I think it can look like this (based on me reading the standard, i've not tested it in one of the other databases that support window functions): SELECT ROW_NUMBER() OVER (ORDER BY id), * FROM table; The over part specify that the whole result set is the window and that the row numbers should be assigned to the result in that order. In practice you want that order to be the same as the whole order I guess SELECT ROW_NUMBER() OVER (ORDER BY id), * FROM table ORDER BY id; Based on some googeling DB2 seems to allow OVER () while oracle does not and you need to specify the ORDER BY (or some other window definition) in the OVER part. Anyway, I just want to point out that row numbers are possible to get in sql2003, even if a simpler syntax like the above can also be useful. Maybe one can just extend sql2003 and let the OVER part be optional all together, and use SELECT ROW_NUMBER(), * FROM table; ps. A window is similar to group by, but you keep all rows in the result set. With group by you get one row from each group in the result set, -- /Dennis Björklund ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for 7.5 feature completion
Harald Fuchs wrote: In article [EMAIL PROTECTED], Christopher Kings-Lynne [EMAIL PROTECTED] writes: Oh, and 'select rowid, * from table' which returns special rowid column that just incrementally numbers each row. Why? Perhaps Christopher meant select row_number() OVER (...) as rowid and then your why could be answered by SQL Standard non-core feature T611 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
On Thu, 2005-08-25 at 19:13 -0400, Alvaro Herrera wrote: Or, slightly different, what are people's most wanted features? My approach to that question has been to try to group together particular use cases. Currently, I see that PostgreSQL is great for web applications (OLTP) and getting better for decision support/data warehousing. There are probably some finer grained groupings that could be made too... I'd be in favour of describing TODO and release history in terms of those possible applications, so people can see progress towards particular solutions. Most of the features we add fall into the category of why would I want that? Has PostgreSQL started slowing down in getting new features, and concentrating mostly on performance issues? Most existing users (of any software product) want more admin capabilities and better performance. If you ask this question of existing users you will be biasing your sample towards those viewpoints. You should ask the question of the people who aren't yet using PostgreSQL ... which was how and why I hacked away at PITR. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for 7.5 feature completion
* optional interface which sends a row typeoid along with each row in a result set Oh, and 'select rowid, * from table' which returns special rowid column that just incrementally numbers each row. Chris ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
On Aug 27, 2005, at 2:45 AM, Heikki Linnakangas wrote: * support for Tutorial D as an alternative to SQL. It would be great for educational purposes. ++ I'd also like to see temporal/interval/period support a la Date/ Darwen/Lorentzos (Temporal Data and the Relational Model). Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for 7.5 feature completion
On Fri, 26 Aug 2005, Heikki Linnakangas wrote: * support for Tutorial D as an alternative to SQL. It would be great for educational purposes. Hmm... we could call it POSTQUEL :-). Gavin ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
Michael Glaesemann said: On Aug 27, 2005, at 2:45 AM, Heikki Linnakangas wrote: * support for Tutorial D as an alternative to SQL. It would be great for educational purposes. ++ I disagree. This strikes me as something that belongs in a research project, not in the core, at least for now. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
Andrew Dunstan [EMAIL PROTECTED] writes: * support for Tutorial D as an alternative to SQL. It would be great for educational purposes. This strikes me as something that belongs in a research project, not in the core, at least for now. For better or worse, Postgres is a SQL engine; I can't imagine trying to support two different query languages at the same time. When the Berkeley guys ripped out PostQUEL and put in SQL, it was a major change, and we are *still* trying to clean up leftover baggage from having originally used a different language with different query semantics. Even if Tutorial D were the greatest thing since sliced bread, supporting it alongside SQL sounds totally impractical. (Reality check: even supporting Oracle's flavor of SQL alongside ours would be an incredible pain. Ask the EnterpriseDB guys how they're doing on that ...) regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
[EMAIL PROTECTED] (Alvaro Herrera) writes: Or, slightly different, what are people's most wanted features? - Vacuum Space Map - Maintain a map of recently-expired rows This allows vacuum to target specific pages for possible free space without requiring a sequential scan. - Deferrable unique constraint - Probably trivially easy would be to add an index to pg_listener - Tougher but better would be to have pg_listener be an in-memory structure rather than being physically represented as a table - MERGE / UPSERT - Config file #includes for postgresql.conf, pg_hba.conf - Some better ability to terminate backends - Automatically updatable views (per SQL 99) -- (format nil [EMAIL PROTECTED] cbbrowne cbbrowne.com) http://cbbrowne.com/info/sap.html I am not a number! I am a free man! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Call for 7.5 feature completion
On Thu, 25 Aug 2005, Josh Berkus wrote: SavePoints be able to use within functions. ( I think this involves making procedures that execute outside of a transaction) Nope, supported in 8.0 for PL/pgSQL. Not sure about other languages. You can't use savepoints, you can trap errors which is implemented using savepoints. You still might want to write code like this: BEGIN SAVEPOINT foo; IF SOME_ERROR_CODE = 1234 THEN ROLLBACK TO SAVEPOINT foo; END ... You can write code like this if you issue each command from the client, say using libpq, but not in pl/pgsql. -- /Dennis Björklund ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
Alvaro wrote: Or, slightly different, what are people's most wanted features? 1. Proper row constructor, such that select (1,2,1) (2,1,1); returns the right answer, and select * from t where (t1,t2,t3) (c1, c2, c3) order by t1,t2,t3 limit 1 returns the right answer and uses a index on t1,t2,t3 if it exists. this is on the TODO. 2. In the planner, a parameterized limit for prepared statements to assume a small value (like 1). 3. Ability to create arrays of composite types (and nest them). Has PostgreSQL started slowing down in getting new features, and concentrating mostly on performance issues? nope! Merlin ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Call for 7.5 feature completion
On N, 2005-08-25 at 19:13 -0400, Alvaro Herrera wrote: We have gone a long way now, even though it was only a year ago. My question for everyone on this list is: What are the few remaining big features that you see missing for PostgreSQL? Or, slightly different, what are people's most wanted features? my pet wishes are : 24/7 OLTP related things * vacuums that ignore other vacuums when deciding what tuples to free (should be mostly done, my patch wasleft to 8.2 due to some doubts by Tom) * non-blocking CREATE INDEX / REINDEX (so indexes can be added to huge tables on busy databases without downtime) * related to last one - command to promote UNIQUE INDEX to PRIMARY KEY. * multiple WAL's, assignable to objects (similaŕ to tablespaces). * better 64-bit support inside db engine. * real background vacuuming, using something like FSM, may be integrated with background writer. * VACUUM FULL/CLUSTER added behaviour of leaving pages half-empty (or any.other-percentage-empty) for good update behaviour. OLAP stuff * table partitioning to move forward. * archive tables (append (==insert) only, only one writer at a time, vacuum needed after rollbacked insert, visibility determined by last valid ctid marker, so will not need most of header fields either). * index-only scans over archive tables (possible without altering current index structure, as visibility can be determined by ctid which is already present in index leaf). Has PostgreSQL started slowing down in getting new features, and concentrating mostly on performance issues? I can't think of this as new features vs. performance thing as many of the new features *are* largely about performance, both on database engine and on user side. -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for 7.5 feature completion
On Thu, Aug 25, 2005 at 07:13:18PM -0400, Alvaro Herrera wrote: Bruce, on May 17, 2004, you wrote: So, yea, I am frustrated. I know these features are hard and complex, but I want them for PostgreSQL, and I want them as soon as possible. I guess what really bugs me is that we are so close to having these few remaining big features, and because they are so complex, they are taking a lot longer to arrive than previous features, and sometimes see a year pass without progress on some items, and that bugs me. This discussion was taking place as we closed the 7.5 development cycle, and we weren't getting PITR, tablespaces, nested transactions, 2PC, the Win32 port, in the release. We have all those things now. We have gone a long way now, even though it was only a year ago. My question for everyone on this list is: What are the few remaining big features that you see missing for PostgreSQL? Or, slightly different, what are people's most wanted features? Has PostgreSQL started slowing down in getting new features, and concentrating mostly on performance issues? Along with all the other cool stuff people have already mentioned, I'd like to see composite types handled better--they're not quite first-class objects yet. Also nice to have: * optional interface which sends a row typeoid along with each row in a result set * more visibility from RULEs into the expression tree generated by the parser and/or other RULEs * SQL/MED (or at least things that would make it easier to implement) * Debugging hooks into all the PLs * Some way of estimating a query progress meter for long-running queries * MULTISET, COLLECT, UNNEST, FUSION, INTERSECT oh, and MERGE! MERGE! MERGE! MERGE! MERGE! MERGE! Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
* Alvaro Herrera ([EMAIL PROTECTED]) wrote: Or, slightly different, what are people's most wanted features? MERGE. Stephen signature.asc Description: Digital signature
Re: [HACKERS] Call for 7.5 feature completion
Dennis Bjorklund wrote: On Thu, 25 Aug 2005, Josh Berkus wrote: SavePoints be able to use within functions. ( I think this involves making procedures that execute outside of a transaction) Nope, supported in 8.0 for PL/pgSQL. Not sure about other languages. You can't use savepoints, you can trap errors which is implemented using savepoints. You still might want to write code like this: BEGIN SAVEPOINT foo; IF SOME_ERROR_CODE = 1234 THEN ROLLBACK TO SAVEPOINT foo; END ... You can write code like this if you issue each command from the client, say using libpq, but not in pl/pgsql. I agree, and I think savepoints would be much more usefull if you could call them from pl/pgsql... ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
On Fri, 2005-08-26 at 13:13 -0400, Nicholas Walker wrote: You can't use savepoints, you can trap errors which is implemented using savepoints. You still might want to write code like this: BEGIN SAVEPOINT foo; IF SOME_ERROR_CODE = 1234 THEN ROLLBACK TO SAVEPOINT foo; END ... I agree, and I think savepoints would be much more usefull if you could call them from pl/pgsql... Maybe if PL/pgSQL had user-defined exceptions then the language's identity of savepoints and exception blocks would be a little easier to work with. Is anything happening with the patch for user-defined exceptions, posted at http://archives.postgresql.org/pgsql-patches/2005-06/msg00475.php (and also discussed elsewhere)? ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
On Thu, 25 Aug 2005, Alvaro Herrera wrote: Or, slightly different, what are people's most wanted features? Since you asked: * concurrent, partial vacuum that would for example only scan pages that happen to be in memory * index-only scans * database assertions * lightwight PITR that wouldn't require to shut down and restore a backup. I'm thinking something like REWIND TO xid 12345. It could be implemented by just setting already-committed transactions as aborted in the clog (vacuum and commit status hint bits need to be disabled beforehand). This would be very handy for automatic regression testing applications. You could load the test database just once, then run test case, rewind, run another test case, rewind and so on. As more disruptive longer-term things: * multiple alternative access plans for prepared statements. For example, if you have a query like SELECT * FROM history WHERE timestamp BETWEEN ? AND ?, the optimal access plan depends a lot on the parameters. Postgres could keep all the plans that are optimal for some combination of parameters, and choose the most efficient one at execution time depending on the parameters. The execution side would actually be quite simple to implement. Introduce a new conditional node type that has 1 child nodes, and a condition that is evaluated at execution time and determines which child node to use. Determining the conditions would require big changes to the planner and estimation routines. * support for Tutorial D as an alternative to SQL. It would be great for educational purposes. - Heikki ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
Alvaro Herrera wrote: Or, slightly different, what are people's most wanted features? Things I would have found useful in the past year or so include: Standards stuff: * Updateable views (easier to use Ruby/Rails's ActiveRecord on legacy data) * The elementary OLAP stuff Contrib related stuff: * Contrib/xml2 working with XML Namespaces. * Some sort of GIST index for querying XML data (XPath? SQL/XML?) * The array functions and indexes from contrib/intarray and contrib/intagg made more general to work with other data types. (I find these contrib modules quite useful) Annoyances: * more sane math with intervals. For example, try: select '0.01 years'::interval, '0.01 months'::interval; Ease of use: * Nice defaults for autovacuum and checkpoints and bgwriter that automatically avoid big I/O spikes by magically distributing I/O in a nice way. Easier COPY for client library authors: * A way to efficiently insert many values like COPY from STDIN from client libraries that don't support COPY from STDIN. Perhaps it could happen through the apparently standards compliant INSERT INTO table VALUES (1,2),(3,4),(5,6) [feature id F641] or perhaps through a new COPY tablename FROM STRING 'a big string instead of stdin' feature that would be easier for clients to support? It seems in most new client libraries COPY FROM STDIN stays broken for quite a long time. Would a alternative COPY FROM A_BIG_STRING be easier for them to support and therefore available more often? Meta-stuff * A failover plus load-balancing (pgpool+slony?) installer for dummies that handles simple cases. * A single place to find all the useful non-core stuff like projects on pgfoundry, gborg, contrib, and various other places around the net (PL/R PL/Ruby Postgis). Perhaps if the postgresql website had a small wiki somewhere where anyone could add links with a short description to any such projects it'd be easier to know what's out there... * Nice APIs and documentation [probably already exists] to continue encouraging projects like PostGIS and PL/R that IMHO are the biggest advantage of postgresql over the commercial vendors' offerings. Oh, and seeing everyone else's response, I suppose I should add MERGE though I haven't actually noticed a need yet. :-) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Call for 7.5 feature completion
Hi all, Our organizations are doing a lot of real time reporting involving queries with multiple tables, and large tables. I found that two features are very nice to have: - Table Partition - Materialized view Thanks, J On 8/26/05, Ron Mayer [EMAIL PROTECTED] wrote: Alvaro Herrera wrote: Or, slightly different, what are people's most wanted features? Things I would have found useful in the past year or so include: Standards stuff: * Updateable views (easier to use Ruby/Rails's ActiveRecord on legacy data) * The elementary OLAP stuff Contrib related stuff: * Contrib/xml2 working with XML Namespaces. * Some sort of GIST index for querying XML data (XPath? SQL/XML?) * The array functions and indexes from contrib/intarray and contrib/intagg made more general to work with other data types. (I find these contrib modules quite useful) Annoyances: * more sane math with intervals. For example, try: select '0.01 years'::interval, '0.01 months'::interval; Ease of use: * Nice defaults for autovacuum and checkpoints and bgwriter that automatically avoid big I/O spikes by magically distributing I/O in a nice way. Easier COPY for client library authors: * A way to efficiently insert many values like COPY from STDIN from client libraries that don't support COPY from STDIN. Perhaps it could happen through the apparently standards compliant INSERT INTO table VALUES (1,2),(3,4),(5,6) [feature id F641] or perhaps through a new COPY tablename FROM STRING 'a big string instead of stdin' feature that would be easier for clients to support? It seems in most new client libraries COPY FROM STDIN stays broken for quite a long time. Would a alternative COPY FROM A_BIG_STRING be easier for them to support and therefore available more often? Meta-stuff * A failover plus load-balancing (pgpool+slony?) installer for dummies that handles simple cases. * A single place to find all the useful non-core stuff like projects on pgfoundry, gborg, contrib, and various other places around the net (PL/R PL/Ruby Postgis). Perhaps if the postgresql website had a small wiki somewhere where anyone could add links with a short description to any such projects it'd be easier to know what's out there... * Nice APIs and documentation [probably already exists] to continue encouraging projects like PostGIS and PL/R that IMHO are the biggest advantage of postgresql over the commercial vendors' offerings. Oh, and seeing everyone else's response, I suppose I should add MERGE though I haven't actually noticed a need yet. :-) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
Ron Mayer wrote: * more sane math with intervals. For example, try: select '0.01 years'::interval, '0.01 months'::interval; Added to TODO: Fix SELECT '0.01 years'::interval, '0.01 months'::interval; -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Call for 7.5 feature completion
Josh Berkus josh@agliodbs.com writes: Oh, yeah I forgot: -- windowing functions (e.g. RANK, RANK OVER, LAST 10) Include this URL or one like it in any TODO about this: http://publib.boulder.ibm.com/infocenter/rb63help/topic/com.ibm.redbrick.doc6.3/sqlrg/sqlrg36.htm#sii-06-62323 It would be wonderful having this stuff but I'll say just skimming it was giving me headaches imagining how much work it would be to do right. Just having a few windowing functions like rank() and functions like running averages would go a long way to making people happy though. -- greg ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
Bruce Momjian pgman@candle.pha.pa.us writes: Ron Mayer wrote: * more sane math with intervals. For example, try: select '0.01 years'::interval, '0.01 months'::interval; Added to TODO: Fix SELECT '0.01 years'::interval, '0.01 months'::interval; Arguably, both of those things should be rejected as errors. What is a fraction of a year? Or a month? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
What everybody else said. :) But if it comes to voting... Anything to improve parallelism is good. Anything reducing blocking (ie: CLUSTER, VACUUM FULL) is good Improved handling of sort_mem (I think this will hit bizgres first) merge :) STATISTICS ON INDEXES! (specifically multi-field indexes) Multiple query plans for bound parameters. Materialized views. I don't know the history behind why Slony is trigger-based, but I think both materialized views and replication would benefit greatly from having a means to tie into WAL (or something similar) instead of using triggers. I would expect this to result in a dramatic speed improvement over triggers, since you would no longer be double-logging. A slick way to do this would be to tie-in to WAL writes that meet certain criteria (namely that they hit a specified table) and store those seperately on-disk. These would be played-back as needed. This mechanism should be useful for both replication and MViews. If you look at one of Oracle's replicaiton options, it's actually just a form of MViews that are on remote machines. Even if we stick with something trigger-based for now I think we should provide a base mechanism that works for both MViews and replication. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Call for 7.5 feature completion
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Ron Mayer wrote: * more sane math with intervals. For example, try: select '0.01 years'::interval, '0.01 months'::interval; Added to TODO: Fix SELECT '0.01 years'::interval, '0.01 months'::interval; Arguably, both of those things should be rejected as errors. What is a fraction of a year? Or a month? What does the standard say we should do with these? Isn't this like interval division, which does work? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
Bruce, on May 17, 2004, you wrote: So, yea, I am frustrated. I know these features are hard and complex, but I want them for PostgreSQL, and I want them as soon as possible. I guess what really bugs me is that we are so close to having these few remaining big features, and because they are so complex, they are taking a lot longer to arrive than previous features, and sometimes see a year pass without progress on some items, and that bugs me. This discussion was taking place as we closed the 7.5 development cycle, and we weren't getting PITR, tablespaces, nested transactions, 2PC, the Win32 port, in the release. We have all those things now. We have gone a long way now, even though it was only a year ago. My question for everyone on this list is: What are the few remaining big features that you see missing for PostgreSQL? Or, slightly different, what are people's most wanted features? Has PostgreSQL started slowing down in getting new features, and concentrating mostly on performance issues? -- Alvaro Herrera (alvherre[a]alvh.no-ip.org) A male gynecologist is like an auto mechanic who never owned a car. (Carrie Snow) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Call for 7.5 feature completion
We have gone a long way now, even though it was only a year ago. My question for everyone on this list is: What are the few remaining big features that you see missing for PostgreSQL? Table partitioning is pretty big but I believe we have that already for 8.2 per Greenplum. Better aggregate performance Real materialized views Anything that goes zoom, zoom, zoom of course! Not to mention the WHOLE todo list :) Sincerely, Joshua D. Drake Or, slightly different, what are people's most wanted features? Has PostgreSQL started slowing down in getting new features, and concentrating mostly on performance issues? -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
On Thu, 25 Aug 2005, Alvaro Herrera wrote: Bruce, on May 17, 2004, you wrote: So, yea, I am frustrated. I know these features are hard and complex, but I want them for PostgreSQL, and I want them as soon as possible. I guess what really bugs me is that we are so close to having these few remaining big features, and because they are so complex, they are taking a lot longer to arrive than previous features, and sometimes see a year pass without progress on some items, and that bugs me. This discussion was taking place as we closed the 7.5 development cycle, and we weren't getting PITR, tablespaces, nested transactions, 2PC, the Win32 port, in the release. We have all those things now. We have gone a long way now, even though it was only a year ago. My question for everyone on this list is: What are the few remaining big features that you see missing for PostgreSQL? Or, slightly different, what are people's most wanted features? SQL: Grouping sets Recursive queries Window functions Updatable views Updatable cursors Materialised views Debug-able PL/PgSQL -- EXPLAIN [ANALYZE] functionality, step through? Cost estimation for functions -- perhaps a pipe dream, I know Performance: Better bulk load 'Continuous' vacuum at a fraction of the IO cost of normal vacuum Multimaster replication General OLTP throughput improvements -- where and how, I'm not sure. Indexes: Bitmap indexes (as opposed to bitmap scans) --- There are other things which would be cool to see, but these are high on the list. Thanks, Gavin ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
On 8/25/05 4:13 PM, Alvaro Herrera [EMAIL PROTECTED] wrote: We have gone a long way now, even though it was only a year ago. My question for everyone on this list is: What are the few remaining big features that you see missing for PostgreSQL? Or, slightly different, what are people's most wanted features? Table partitioning would be huge, but it looks like that is on its way. Index-organized tables are the most significant thing at the top of my wish list, as that would generate a huge performance increase for much of what I spend my time on with PostgreSQL. There is currently no good way to approximate it. J. Andrew Rogers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Call for 7.5 feature completion
Alvaro, We have gone a long way now, even though it was only a year ago. My question for everyone on this list is: What are the few remaining big features that you see missing for PostgreSQL? -- on-disk bitmaps and composite indexes (due out for Bizgres in about a month) -- More table partitioning stuff -- materialized view support -- streams (per TelegraphCQ) -- database ASSERTIONS -- clustering (SlonyII) -- multi-threaded/process query execution (i.e. one query, multiple processors) -- more robust message queing -- SQL99 TYPES (aka Packages) -- Recursive Joins -- MERGE -- interactive/automated database performance tuning -- index-only access -- automated creation of updatable views Has PostgreSQL started slowing down in getting new features, and concentrating mostly on performance issues? Hmmm, I don't think so. We will eventually, but there's still plenty of features left. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for 7.5 feature completion
Gavin Sherry wrote: Or, slightly different, what are people's most wanted features? SQL: Grouping sets Recursive queries Window functions Updatable views Updatable cursors Materialised views Debug-able PL/PgSQL -- EXPLAIN [ANALYZE] functionality, step through? Cost estimation for functions -- perhaps a pipe dream, I know and Merge (which I know Gavin also wants). cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
Alvaro, -- on-disk bitmaps and composite indexes (due out for Bizgres in about a month) -- More table partitioning stuff -- materialized view support -- streams (per TelegraphCQ) -- database ASSERTIONS -- clustering (SlonyII) -- multi-threaded/process query execution (i.e. one query, multiple processors) -- more robust message queing -- SQL99 TYPES (aka Packages) -- Recursive Joins -- MERGE -- interactive/automated database performance tuning -- index-only access -- automated creation of updatable views Oh, yeah I forgot: -- windowing functions (e.g. RANK, RANK OVER, LAST 10) -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Call for 7.5 feature completion
On Thu, 2005-08-25 at 19:13 -0400, Alvaro Herrera wrote: Bruce, on May 17, 2004, you wrote: So, yea, I am frustrated. I know these features are hard and complex, but I want them for PostgreSQL, and I want them as soon as possible. I guess what really bugs me is that we are so close to having these few remaining big features, and because they are so complex, they are taking a lot longer to arrive than previous features, and sometimes see a year pass without progress on some items, and that bugs me. This discussion was taking place as we closed the 7.5 development cycle, and we weren't getting PITR, tablespaces, nested transactions, 2PC, the Win32 port, in the release. We have all those things now. We have gone a long way now, even though it was only a year ago. My question for everyone on this list is: What are the few remaining big features that you see missing for PostgreSQL? Or, slightly different, what are people's most wanted features? I have an immediate use for: * Identity/generator support (per standard) * Merge (update/insert as required) * Multi-CPU sorts. Take a large single sort like an index creation and split the work among multiple CPUs. -- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
Rod Taylor wrote: * Multi-CPU sorts. Take a large single sort like an index creation and split the work among multiple CPUs. This really implies threading, doesn't it? And presumably it would have many possible uses besides this one for doing parallel work, e.g. maybe the planner could evaluate several alternative plans in parallel. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
We have gone a long way now, even though it was only a year ago. My question for everyone on this list is: What are the few remaining big features that you see missing for PostgreSQL? Or, slightly different, what are people's most wanted features? Oh, and MERGE :D Chris ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
On Thu, 2005-08-25 at 21:27 -0400, Andrew Dunstan wrote: Rod Taylor wrote: * Multi-CPU sorts. Take a large single sort like an index creation and split the work among multiple CPUs. This really implies threading, doesn't it? And presumably it would have many possible uses besides this one for doing parallel work, e.g. maybe the planner could evaluate several alternative plans in parallel. I don't think threading is needed. I pictured PostgreSQL spawning one process per CPU explicitly for sorting which standard backends could use as required to do batch work. Not necessarily easy to do but it would sure be handy. -- ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
We have gone a long way now, even though it was only a year ago. My question for everyone on this list is: What are the few remaining big features that you see missing for PostgreSQL? Or, slightly different, what are people's most wanted features? * Recursive unions (ie. WITH recursive) * CUBE ROLLUP * The rest of the oracle analytic functions (http://www.akadia.com/services/ora_analytic_functions.html) I'm happy with new features and performance, but I'd really like to be able to do complex analysis of the huge statistics tables I have :) Chris ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for 7.5 feature completion
Rod Taylor wrote: On Thu, 2005-08-25 at 19:13 -0400, Alvaro Herrera wrote: Bruce, on May 17, 2004, you wrote: So, yea, I am frustrated. I know these features are hard and complex, but I want them for PostgreSQL, and I want them as soon as possible. I guess what really bugs me is that we are so close to having these few remaining big features, and because they are so complex, they are taking a lot longer to arrive than previous features, and sometimes see a year pass without progress on some items, and that bugs me. This discussion was taking place as we closed the 7.5 development cycle, and we weren't getting PITR, tablespaces, nested transactions, 2PC, the Win32 port, in the release. We have all those things now. We have gone a long way now, even though it was only a year ago. My question for everyone on this list is: What are the few remaining big features that you see missing for PostgreSQL? Or, slightly different, what are people's most wanted features? I have an immediate use for: * Identity/generator support (per standard) * Merge (update/insert as required) * Multi-CPU sorts. Take a large single sort like an index creation and split the work among multiple CPUs. I am just a novice end user, but I would like to see: SavePoints be able to use within functions. ( I think this involves making procedures that execute outside of a transaction) Cross Database references. (Available through dblink, but it would be better if it was supported natively) The ability to say create function foo () returns setof record(int, int , int). I believe this is coming in the next release though. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
Rod Taylor wrote: On Thu, 2005-08-25 at 21:27 -0400, Andrew Dunstan wrote: Rod Taylor wrote: * Multi-CPU sorts. Take a large single sort like an index creation and split the work among multiple CPUs. This really implies threading, doesn't it? And presumably it would have many possible uses besides this one for doing parallel work, e.g. maybe the planner could evaluate several alternative plans in parallel. I don't think threading is needed. I pictured PostgreSQL spawning one process per CPU explicitly for sorting which standard backends could use as required to do batch work. This is one area where PostgreSQL needs a lot of work to catch up to the competition. Oracle, DB2, Ingres, even SQL Server Enterprise edition all have parallel query capabilities. I have an older 8-processor Sun Enterprise 3500, as an example. It still has use with other vendors' database products due to their parallel feature set (make -j 9 is nice too), but behaves like the boat-anchor it is w.r.t. PostgreSQL. Mike Mascari ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
Nicholas, You are a novice user, aren't you? ;-) I am just a novice end user, but I would like to see: SavePoints be able to use within functions. ( I think this involves making procedures that execute outside of a transaction) Nope, supported in 8.0 for PL/pgSQL. Not sure about other languages. Cross Database references. (Available through dblink, but it would be better if it was supported natively) You'll have to argue this one. We don't have them on purpose. Generally when people want cross-database queries the problem is that they really should be using schema. The ability to say create function foo () returns setof record(int, int , int). I believe this is coming in the next release though. Well, we've had this for 3 versions as CREATE TYPE ... CREATE FUNCTION. INOUT parameters in 8.1 will give you the above, effectively. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Call for 7.5 feature completion
David Garamond wrote: Robert Treat wrote: Given that the cygwin version is currently labeled as not ready for production I would say you are right. The truth is that many will never declare win32 good for production simply because of the OS it runs on, but we still want to make it as solid as possible. People _do_ use postgresql+cygwin in production environments though (see the pgsql-cygwin archive). And I suspect people _will_ use 7.5 for win32 in production, despite the release notes and the website clearly saying it's not production ready. Why? 1) The version number is 7.5 and many people will presume the ports are more or less equal in quality/maturity since they have the same version number; 2) People don't read release notes. See the various reviews on the recently released Fedora Core 2, complaining about how it doesn't support MP3 or DVD playback, despite the [legal] issues having been known and documented since Red Hat 8. Strangely enough, these people (who don't read release notes) _do_ write public reviews. They will badmouth PostgreSQL, saying it's unstable, crashes a lot, MySQL being much much more rock solid, etc etc. I suggest we label the win32 port as 7.5 ALPHA or 7.5 DANGEROUS :-) My concern is about the fact the fact that Postgresql rely on the OS about his ability to optimize memory access. Do we have any possibility at this stage to compare Postgresql performance on top of Win32 with other products for this platform ? I think that Postgresql with this version is going to address a specific class of final users that right now are using what ? I don't think the response is: users that now are using postgresql+cygwin. Can the first version of postgresql for Win32 compared with other products? I really hope yes, you know: there is no a *second* possibility to do a *first* good impression. Regards Gaetano Mendola ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
We could perhaps do something similar to the Apache 1.3 win platform notes, where they (still) say *something* like : Apache on windows is not as stable as on unix... but is being actively improved all the time This is a bit more positive than it's dangerous!. As for people not reading the release notes - we could display the platform note (or an href to it) prominently on the download page (they may still not read that...but it has become a matter of choice at that point...). regards Mark David Garamond wrote: Robert Treat wrote: Given that the cygwin version is currently labeled as not ready for production I would say you are right. The truth is that many will never declare win32 good for production simply because of the OS it runs on, but we still want to make it as solid as possible. People _do_ use postgresql+cygwin in production environments though (see the pgsql-cygwin archive). And I suspect people _will_ use 7.5 for win32 in production, despite the release notes and the website clearly saying it's not production ready. Why? 1) The version number is 7.5 and many people will presume the ports are more or less equal in quality/maturity since they have the same version number; 2) People don't read release notes. See the various reviews on the recently released Fedora Core 2, complaining about how it doesn't support MP3 or DVD playback, despite the [legal] issues having been known and documented since Red Hat 8. Strangely enough, these people (who don't read release notes) _do_ write public reviews. They will badmouth PostgreSQL, saying it's unstable, crashes a lot, MySQL being much much more rock solid, etc etc. I suggest we label the win32 port as 7.5 ALPHA or 7.5 DANGEROUS :-) ---(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] Call for 7.5 feature completion
Robert Treat wrote: Given that the cygwin version is currently labeled as not ready for production I would say you are right. The truth is that many will never declare win32 good for production simply because of the OS it runs on, but we still want to make it as solid as possible. People _do_ use postgresql+cygwin in production environments though (see the pgsql-cygwin archive). And I suspect people _will_ use 7.5 for win32 in production, despite the release notes and the website clearly saying it's not production ready. Why? 1) The version number is 7.5 and many people will presume the ports are more or less equal in quality/maturity since they have the same version number; 2) People don't read release notes. See the various reviews on the recently released Fedora Core 2, complaining about how it doesn't support MP3 or DVD playback, despite the [legal] issues having been known and documented since Red Hat 8. Strangely enough, these people (who don't read release notes) _do_ write public reviews. They will badmouth PostgreSQL, saying it's unstable, crashes a lot, MySQL being much much more rock solid, etc etc. I suggest we label the win32 port as 7.5 ALPHA or 7.5 DANGEROUS :-) -- dave ---(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] Call for 7.5 feature completion
On Thu, 2004-05-20 at 19:59, Gaetano Mendola wrote:
Greg Copeland wrote:
On Tue, 2004-05-18 at 09:30, Andrew Sullivan wrote:
On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote:
fact that checkpoints, vacuum runs and pg_dumps bog down their machines
to the state where simple queries take several seconds care that much
for any Win32 port? Do you think it is a good sign for those who have
Yes. I am one such person, but from the marketing side of things, I
understand perfectly well what failing to deliver on Win32 again will
cost. It's not important to _me_, but that doesn't mean it's
unimportant to the project.
My primary fear about delivering Win32 with all of these other great
features is that, IMO, there is a higher level of risk associated with
these advanced features. At the same time, this will be the first trial
for many Win32 users. Should there be some problems, in general, or
worse, specific to Win32 users as it relates to these new features, it
could cost some serious Win32/PostgreSQL community points. A troubled
release which is experienced by Win32 users is going to be a battle cry
for MySQL.
I believe that the very first Win32 native version will be declared not
realy ready for production, am I wrong ?
Given that the cygwin version is currently labeled as not ready for
production I would say you are right. The truth is that many will never
declare win32 good for production simply because of the OS it runs on,
but we still want to make it as solid as possible.
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] Call for 7.5 feature completion
Marc, what is wrong with the nightly snapshots that are created? Nothing. I was just clueless that this was set up. So, the 2nd step is to find a likely victi^H^H^H^Holunteer to coordinate platform/feature testing among our large population of mailing list users. Easier said than done ... -- -Josh Berkus Aglio Database Solutions San Francisco ---(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] Call for 7.5 feature completion
Greg Copeland wrote: On Tue, 2004-05-18 at 09:30, Andrew Sullivan wrote: On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote: fact that checkpoints, vacuum runs and pg_dumps bog down their machines to the state where simple queries take several seconds care that much for any Win32 port? Do you think it is a good sign for those who have Yes. I am one such person, but from the marketing side of things, I understand perfectly well what failing to deliver on Win32 again will cost. It's not important to _me_, but that doesn't mean it's unimportant to the project. My primary fear about delivering Win32 with all of these other great features is that, IMO, there is a higher level of risk associated with these advanced features. At the same time, this will be the first trial for many Win32 users. Should there be some problems, in general, or worse, specific to Win32 users as it relates to these new features, it could cost some serious Win32/PostgreSQL community points. A troubled release which is experienced by Win32 users is going to be a battle cry for MySQL. I believe that the very first Win32 native version will be declared not realy ready for production, am I wrong ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What can be done? Well, money from Fujitsu and other companies (Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit some of these bigger items, so hopefully that will move us forward in these complex areas. I am not sure what could have been done to push some of these projects along faster. Perhaps some more public cajoling of the masses into helping out would be good. Not just development but testing. Occasional posts on general asking people to help test Win32 and PITR for example, or a prominent link on the main page asking people to try out the latest Win32. It may not be beta-ready yet, but it surely could not hurt to have people start testing as soon as possible. I'm one of those that should probably be testing early. As it stands, I'm subscribed to -hackers and if I downloaded a snapshot from today I still don't know what it is I'd be testing. How about a series of mini-releases (say) every 8 weeks - 7 weeks patching, 1 week stabilising. That would provide something solid enough to do some development work with, but you're not going to cry if (e.g.) nested transactions didn't work with system tables. Is that a plausible situation, or madness from a developer-resources point of view? -- Richard Huxton Archonet Ltd ---(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] Call for 7.5 feature completion
On Wed, 19 May 2004, Bruce Momjian wrote: Marc G. Fournier wrote: There is no such thing as too close to feature freeze, nor has there ever been in the past ... other then missing it altogether. Unless there are some serious flaws in the implementation, submitting it on May 31st would get it in ...it isn't expecting to be rock solid, bug free, that is what the beta period is to work out ... What is expected, though, is that you won't disappear after its committed, so that you can fix any bugs reported in a timely manner ... Not completely true. If a patch needs major rework or the implemention isn't acceptable, it might be rejected and have to wait --- it has happened before, and PITR might not make it because the April 1 patch wasn't an acceptable implementation. Which is why I stateed unless there are some serious flaws in ... :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] Call for 7.5 feature completion
Richard Huxton wrote: What can be done? Well, money from Fujitsu and other companies (Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit some of these bigger items, so hopefully that will move us forward in these complex areas. I am not sure what could have been done to push some of these projects along faster. Perhaps some more public cajoling of the masses into helping out would be good. Not just development but testing. Occasional posts on general asking people to help test Win32 and PITR for example, or a prominent link on the main page asking people to try out the latest Win32. It may not be beta-ready yet, but it surely could not hurt to have people start testing as soon as possible. I'm one of those that should probably be testing early. As it stands, I'm subscribed to -hackers and if I downloaded a snapshot from today I still don't know what it is I'd be testing. How about a series of mini-releases (say) every 8 weeks - 7 weeks patching, 1 week stabilising. That would provide something solid enough to do some development work with, but you're not going to cry if (e.g.) nested transactions didn't work with system tables. Is that a plausible situation, or madness from a developer-resources point of view? We actually don't need more testing. We already know the missing issues with most features. The big problem is finding folks who have the time to ramp up the steep learning curve needed to contribute to these complex features. -- 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] Call for 7.5 feature completion
Richard Huxton [EMAIL PROTECTED] writes: I'm one of those that should probably be testing early. As it stands, I'm subscribed to -hackers and if I downloaded a snapshot from today I still don't know what it is I'd be testing. How about a series of mini-releases (say) every 8 weeks - 7 weeks patching, 1 week stabilising. I think that would be fairly useless. CVS tip is rarely broken to the extent of not being worthy of testing --- we simply won't apply patches that break it, because they'd interfere with other development work. The main downside of testing a snapshot, as I see it, is that the snapshot is virtually certain not to be initdb-compatible with either the previous release or the upcoming one. Mini-releases would have that problem too, and so I don't really see what they add in terms of testability. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
People, So, why tie it into the PostgreSQL source tree? Won't it be popular enough to live on its own, that it has to be distributed as part of the core? Personally, I find it rather inconsistent to have any PL, other than PL/pgSQL, as part of the core distribution -- when we are pushing the interfaces, such as JDBC and libpqxx to seperate modules in pgFoundry. Either we're trying to lighten up the core, or we're not.But right now there seems to be no logic in operation. I do think, though, that we need some system to build RPMs for all the pgFoundry stuff ... -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
Tom, The main downside of testing a snapshot, as I see it, is that the snapshot is virtually certain not to be initdb-compatible with either the previous release or the upcoming one. Mini-releases would have that problem too, and so I don't really see what they add in terms of testability. The main purpose of mini-releases would be to make testing more accessable to newbies who find anon-CVS intimidating. However, there's no point in worrying about lowering the barriers of entry unless we have a program and a coordinator to make some kind of real use of these newbies' feedback. Anybody wanna volunteer to be 7.5 testing coordinator? -- Josh Berkus Aglio Database Solutions San Francisco ---(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] Call for 7.5 feature completion
Josh Berkus [EMAIL PROTECTED] writes: The main purpose of mini-releases would be to make testing more accessable to newbies who find anon-CVS intimidating. Who said anything about anon-CVS? There are the nightly snapshots for those who want a tarball. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
Josh Berkus wrote: People, So, why tie it into the PostgreSQL source tree? Won't it be popular enough to live on its own, that it has to be distributed as part of the core? Personally, I find it rather inconsistent to have any PL, other than PL/pgSQL, as part of the core distribution -- when we are pushing the interfaces, such as JDBC and libpqxx to seperate modules in pgFoundry. Either we're trying to lighten up the core, or we're not.But right now there seems to be no logic in operation. I do think, though, that we need some system to build RPMs for all the pgFoundry stuff ... Server-side PLs might have quite different requirements from Client Interfaces. I don't think you can simply extrapolate in this way. Personally, I hate the idea of having to write stuff like this example Joe Conway gave the other day from PL/R: #if (CATALOG_VERSION_NO = 200211021) #define PG_VERSION_73_COMPAT #elif (CATALOG_VERSION_NO = 200310211) #define PG_VERSION_74_COMPAT #else #define PG_VERSION_75_COMPAT #endif and all the consequent mess. Yuck. Frankly, although I am a relative newcomer around here, I am not convinced that lightening the core has been a great success, or can be made to be so. Certainly Peter's comments on the history to date suggest that a re-evaluation might be in order. cheers andrew ---(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] Call for 7.5 feature completion
On Wed, 2004-05-19 at 12:55, Josh Berkus wrote:
Tom,
The main downside of testing a snapshot, as I see it, is that the
snapshot is virtually certain not to be initdb-compatible with either
the previous release or the upcoming one. Mini-releases would have
that problem too, and so I don't really see what they add in terms of
testability.
The main purpose of mini-releases would be to make testing more accessable to
newbies who find anon-CVS intimidating.
FWIW we already do nightly tarballs that people can use to build from if
they want...
What might be handy is an alpha build of the win32 version once the
folks developing it feel it's stable enough to merit such a thing...
Course as Bruce mentioned in a post somewhere 'round here, testing is
not the real deficiency here, people who can help code is.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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] Call for 7.5 feature completion
Andrew Dunstan wrote: Frankly, although I am a relative newcomer around here, I am not convinced that lightening the core has been a great success, or can be made to be so. Certainly Peter's comments on the history to date suggest that a re-evaluation might be in order. Moving stuff out makes their release schedules and community involvement independent, but from a code activity and ease-of-use perspective, it has been a general failure, with only a few successes. -- 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] Call for 7.5 feature completion
Robert Treat wrote: On Wed, 2004-05-19 at 12:55, Josh Berkus wrote: Tom, The main downside of testing a snapshot, as I see it, is that the snapshot is virtually certain not to be initdb-compatible with either the previous release or the upcoming one. Mini-releases would have that problem too, and so I don't really see what they add in terms of testability. The main purpose of mini-releases would be to make testing more accessable to newbies who find anon-CVS intimidating. FWIW we already do nightly tarballs that people can use to build from if they want... What might be handy is an alpha build of the win32 version once the folks developing it feel it's stable enough to merit such a thing... The Win32 project page already has nightly Win32 builds courtesy of Magnus. -- 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] Call for 7.5 feature completion
What might be handy is an alpha build of the win32 version once the folks developing it feel it's stable enough to merit such a thing... http://www.hagander.net/pgsql/win32snap/ Merlin has set a job up that compiles it daily. It may be broken right this minute because of the exec stuff, but it updates there normally. The link is also on the win32 status page. //Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
Peter Eisentraut [EMAIL PROTECTED] writes: Marc G. Fournier wrote: That is the plan ... unless someone knows a reason why they can't be built independently of the core? How about this one: Everything we have moved from the core to gborg so far has been a miserable failure. JDBC seems to be doing fine ... but I think that exception just proves your point. If there's not a viable community around a particular piece of code, pushing it out to gborg/pgFoundry won't magically create one. I strongly disagree with moving out the existing PLs; it's just a whole lot easier to maintain them alongside the backend. (This is especially true of plpgsql of course, but it is very common that global edits hit the other PLs as well.) I think Joe Conway's experience with maintaining plR separately shows the overhead involved. I would like to see plperlNG eventually supplant the existing plperl in core CVS. If it weren't for the circular-build-dependency issue, I'd probably be in favor of pulling in plPHP too. I do see a point to having pgFoundry though, which is that it allows more people to be granted direct commit access to the bits of code they are working on. For the core project, I think we should continue the present policy of keeping commit access pretty closely held, so pulling all that stuff back in would make the committers a real bottleneck. With separate projects we can let each project determine its own commit access policies. I agree with the opinion that we need to figure out how to produce more-or-less-integrated release filesets from multiple projects. There's too much stuff being pushed out for development or release engineering reasons that users want to see as part of the standard product. We've let the lure of separate projects can have separate release schedules blind us to the fact that for most projects there's not really any benefit there. Client-side libraries like JDBC can get some benefit, but server-side stuff I don't think so. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
Josh Berkus wrote: People, So, why tie it into the PostgreSQL source tree? Won't it be popular enough to live on its own, that it has to be distributed as part of the core? Personally, I find it rather inconsistent to have any PL, other than PL/pgSQL, as part of the core distribution -- when we are pushing the interfaces, such as JDBC and libpqxx to seperate modules in pgFoundry. Either we're trying to lighten up the core, or we're not.But right now there seems to be no logic in operation. I do think, though, that we need some system to build RPMs for all the pgFoundry stuff ... As far as this discussion is concerned I personally think that there is just one way to satisfy everybody. I we had a PostgreSQL most wanted distribution including PL/* as well as some other modules we could save people compiling PostgreSQL from source a lot of work. The core itself would be cleaner (which is the target of moving things out) and everybody would be happy? If people think this is a good idea I could compile and maintain this (source) distribution ... Best regards, Hans -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/720/10 1234567 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] Call for 7.5 feature completion
Tom, The main purpose of mini-releases would be to make testing more accessable to newbies who find anon-CVS intimidating. Who said anything about anon-CVS? There are the nightly snapshots for those who want a tarball. Really? Where are they? I'd like to be able to refer people. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
Josh Berkus wrote: Tom, The main purpose of mini-releases would be to make testing more accessable to newbies who find anon-CVS intimidating. Who said anything about anon-CVS? There are the nightly snapshots for those who want a tarball. Really? Where are they? I'd like to be able to refer people. On the ftp server under /dev. -- 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] Call for 7.5 feature completion
On Wed, May 19, 2004 at 09:20:57AM +0800, Christopher Kings-Lynne wrote: Seriously though, we all have the roles that we play. I don't think redirecting specific resources to other resources will help beyond slowing up the original resources. And now Neil's on holidays :) Not yet I hope. I'm still counting on the list rewrite being done. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Limítate a mirar... y algun día veras ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Marc G. Fournier wrote: That is the plan ... unless someone knows a reason why they can't be built independently of the core? How about this one: Everything we have moved from the core to gborg so far has been a miserable failure. JDBC seems to be doing fine ... but I think that exception just proves your point. If there's not a viable community around a particular piece of code, pushing it out to gborg/pgFoundry won't magically create one. I strongly disagree with moving out the existing PLs; it's just a whole lot easier to maintain them alongside the backend. (This is especially true of plpgsql of course, but it is very common that global edits hit the other PLs as well.) I think Joe Conway's experience with maintaining plR separately shows the overhead involved. I would like to see plperlNG eventually supplant the existing plperl in core CVS. If it weren't for the circular-build-dependency issue, I'd probably be in favor of pulling in plPHP too. Amen. plperlNG was always intended as a replacement. In fact, one of the reasons I'm a bit sad about us rushing to feature freeze on 1 June is that Joshua and I had hoped to get a greatly beefed up plperl ready in time for 7.5, but I don't think we can make June 1. I do see a point to having pgFoundry though, which is that it allows more people to be granted direct commit access to the bits of code they are working on. Indeed. One of the great uses of pgfoundry is as a community site that can be used for things intended for eventual inclusion in the core but not yet ready for it. For the core project, I think we should continue the present policy of keeping commit access pretty closely held, so pulling all that stuff back in would make the committers a real bottleneck. With separate projects we can let each project determine its own commit access policies. It's a timing thing. When plperlng is ready we will present a largish patch or set of patches. At that time the separate project would shut down and plperl would once again be maintained as part of the core. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
Amen. plperlNG was always intended as a replacement. In fact, one of the reasons I'm a bit sad about us rushing to feature freeze on 1 June is that Joshua and I had hoped to get a greatly beefed up plperl ready in time for 7.5, but I don't think we can make June 1. I don't think we will make it either. June 15th maybe. Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
On Wed, 19 May 2004, Josh Berkus wrote: People, So, why tie it into the PostgreSQL source tree? Won't it be popular enough to live on its own, that it has to be distributed as part of the core? Personally, I find it rather inconsistent to have any PL, other than PL/pgSQL, as part of the core distribution -- when we are pushing the interfaces, such as JDBC and libpqxx to seperate modules in pgFoundry. Actually, JDBC, libpqxx, ODBC, plPHP, plPerlNG are all really easy to push over to pgFoundry ... they have very active, and visible, developers responsible for them ... is anyone out there directing work on pl/pgsql or pl/TCL? If so, they are easy to move also ... Either we're trying to lighten up the core, or we're not. But right now there seems to be no logic in operation. Its easier to *not add* something to core (ie. plPHP/plPerlNG) then it is to remove something (see JDBC) ... 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]
Re: [HACKERS] Call for 7.5 feature completion
On Wed, 19 May 2004, Andrew Dunstan wrote: Personally, I hate the idea of having to write stuff like this example Joe Conway gave the other day from PL/R: #if (CATALOG_VERSION_NO = 200211021) #define PG_VERSION_73_COMPAT #elif (CATALOG_VERSION_NO = 200310211) #define PG_VERSION_74_COMPAT #else #define PG_VERSION_75_COMPAT #endif Why not have seperate branches in CVS for each version? Branch on similar dates to the core distribution itself? 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]
Re: [HACKERS] Call for 7.5 feature completion
On Wed, 19 May 2004, Josh Berkus wrote: Tom, The main downside of testing a snapshot, as I see it, is that the snapshot is virtually certain not to be initdb-compatible with either the previous release or the upcoming one. Mini-releases would have that problem too, and so I don't really see what they add in terms of testability. The main purpose of mini-releases would be to make testing more accessable to newbies who find anon-CVS intimidating. what is wrong with the nightly snapshots that are created? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Core vs non-Core (Was: Re: [HACKERS] Call for 7.5 feature completion)
On Wed, 19 May 2004, [ISO-8859-1] Hans-Jürgen Schönig wrote: If people think this is a good idea I could compile and maintain this (source) distribution ... I'd love to see something like this ... One question I have is what would it take to extend teh build system in core so that it was easier to do this? For instance, for those wishing to do something like this, what would it take to have it so that you could 'cvs checkout': pgsql (the core) pgsql/src/interfaces/jdbc (from pgfoundry) pgsql/src/interfaces/odbc (from pgfoundry) I know that pulling in the various source codes isn't a difficult script to write, but how about adding in the building of the included modules? Maybe have the optional modules in a pgsql/src/modules directory? I know its doable ... apache does it ... ... and I've seen other software/projects where configure in the root calls configure in the modules directory itself, so that's doable ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
On Wed, 19 May 2004, Bruce Momjian wrote: The Win32 project page already has nightly Win32 builds courtesy of Magnus. Do you want to setup an scp into the main ftp site so that the mirrors catch them as well? Might make it easier for ppl to get ahold of it ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier said: On Wed, 19 May 2004, Josh Berkus wrote: People, So, why tie it into the PostgreSQL source tree? Won't it be popular enough to live on its own, that it has to be distributed as part of the core? Personally, I find it rather inconsistent to have any PL, other than PL/pgSQL, as part of the core distribution -- when we are pushing the interfaces, such as JDBC and libpqxx to seperate modules in pgFoundry. Actually, JDBC, libpqxx, ODBC, plPHP, plPerlNG are all really easy to push over to pgFoundry ... they have very active, and visible, developers responsible for them ... is anyone out there directing work on pl/pgsql or pl/TCL? If so, they are easy to move also ... Either we're trying to lighten up the core, or we're not. But right now there seems to be no logic in operation. Its easier to *not add* something to core (ie. plPHP/plPerlNG) then it is to remove something (see JDBC) ... plperlng is not something not in the core. It is a project to improve something that *is* in the core. That has always been my intention, and it is clear from his comments that it has always been Joshua Drake's too. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier said: On Wed, 19 May 2004, Andrew Dunstan wrote: Personally, I hate the idea of having to write stuff like this example Joe Conway gave the other day from PL/R: #if (CATALOG_VERSION_NO = 200211021) #define PG_VERSION_73_COMPAT #elif (CATALOG_VERSION_NO = 200310211) #define PG_VERSION_74_COMPAT #else #define PG_VERSION_75_COMPAT #endif Why not have seperate branches in CVS for each version? Branch on similar dates to the core distribution itself? And thus demolish your argument that it is in the interests of projects to have independent release dates. And make the task more complex. All this will do is make life harder. We should be about making it easier. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
On Wed, 19 May 2004, Andrew Dunstan wrote: Why not have seperate branches in CVS for each version? Branch on similar dates to the core distribution itself? And thus demolish your argument that it is in the interests of projects to have independent release dates. And make the task more complex. How do you figure that? If you do a 7.4 branch of a project, around the same time as 7.4 of PostgreSQL, you have code that is specific to that release that you can apply patches/improvements to. By being a seperate project, you don't hvae to wait for 7.4.1 to be released in order to release a new version of the project ... I'm not even say call it a 7.4 branch ... just associate it with it ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
Am Tuesday 18 May 2004 07:40 schrieb Greg Copeland: From the FAQ (http://www.drbd.org/316.html): Q: Can XFS be used with DRBD? A: XFS uses dynamic block size, thus DRBD 0.7 or later is needed. Hope we're talking about the same project. ;) Hmmm, interesting. But I did not find 0.7 on the history page http://www.drbd.org/releases.html maybe it's not release status yet - thus no option for now. Regards, Mario Weilguni ---(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] Call for 7.5 feature completion
Marc G. Fournier wrote: That is the plan ... unless someone knows a reason why they can't be built independently of the core? How about this one: Everything we have moved from the core to gborg so far has been a miserable failure. The code is no longer maintained, or maintained by three different competing groups, the documentation has disappeared, the portability is no longer taken care of, and only the bravest souls even dare look at the stuff. I think before you move anything more, you need to have a strong, convincing community on the receiving side rather than just kicking things out and hoping someone will pick it up. Just because it can be built separately doesn't mean everything needs to be. ---(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] Call for 7.5 feature completion
Joshua D. Drake wrote: Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to replace plPerl, I was talking with Bruce and he seemed to think that (as long as the code was good enough) that we could incorporate plPHP??? One reason against including plPHP in the core would be that it would create a circular build dependency between the packages postgresql and php. I think we should rather avoid that. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
How about this one: Everything we have moved from the core to gborg so far has been a miserable failure. The code is no longer maintained, or maintained by three different competing groups, the documentation has disappeared, the portability is no longer taken care of, and only the bravest souls even dare look at the stuff. I think before you move anything more, you need to have a strong, convincing community on the receiving side rather than just kicking things out and hoping someone will pick it up. Just because it can be built separately doesn't mean everything needs to be. Above looks quite true for me too. -- Tatsuo Ishii ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
Peter Eisentraut wrote: How about this one: Everything we have moved from the core to gborg so far has been a miserable failure. The code is no longer maintained, or maintained by three different competing groups, the documentation has disappeared, the portability is no longer taken care of, and only the bravest souls even dare look at the stuff. I think before you move anything more, you need to have a strong, convincing community on the receiving side rather than just kicking things out and hoping someone will pick it up. Just because it can be built separately doesn't mean everything needs to be. I guess the key thing is that pgFoundry shouldn't be a community distinct from the core. The same community standards need to apply on both sides of the fence. What has happened here echoes the experiences of the PHP project very closely. PHP, too, thought that the core was getting too big for efficient release coordination, and started moving extensions to PECL, an extension library bolted on the side of PEAR. Trouble is, nobody wants to be forced into the ghetto. The only way to make pgFoundry work is to minimize the downside of living there. Consider these: - Don't move just inessential projects. Move absolutely essential projects to push end-user and developer adoption. - Have a tier of official projects that are actively endorsed by and within the core distribution. Don't be afraid to pick a favorite solution within a class (for example in replication). - Discourage other developers from ignoring pgFoundry projects. For the official tier, this could mean sending commit messages to pgsql-committers, patches to pgsql-patches, and having the discussions here. Resist the urge to start project-specific mailing lists unless absolutely essential. Have everyone know that the pgFoundry/core distinction only exists for release engineering purposes, and that it can't be allowed to split the community. - Invest in integrating pgFoundry tools into the core distribution. For example, official projects should have makefiles included in the core that'd download and compile the latest compatible version. Components as important as JDBC and some of the procedural languages could be distributed this way. mk ---(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] Call for 7.5 feature completion
Marko Karppinen wrote: I guess the key thing is that pgFoundry shouldn't be a community distinct from the core. The same community standards need to apply on both sides of the fence. [snip] Thanks Marko, you just wrote exactly what I was concerned about with features rather than applications being in pgfoundry. The only thing I'd add is that we need to separate development from delivery. The important thing as an end-user is not where the CVS is kept or how things are kept in-sync but: 1. Can I get hold of it easily? 2. Is it mentioned in the manual? 3. Do I know what versions of PG/other it needs? pl/PHP etc might not need to be in the core CVS or tar.gz, but probably do need to be in a pl/ or plugins/ directory on the main site. If it takes a week or two (after release) for the various plugins to appear, that's fine - no-one upgrades a production system on day 1 anyway. Perhaps this is the best way to look at it - when the .rpm's/.deb's are put together what does the community want in them? -- Richard Huxton Archonet Ltd ---(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
