Re: [GENERAL] Plans for 8.2?
Sure, but it still means installing an external tool, which requires PHP, which isn't trivial to install in it's own right. And afaik there's still no way to find out how much IO each query did, how much CPU was spent, if any sorts overflowed, etc., etc. Exactly my point, and thus the reason why I'd like to see such functionality implemented. Since I haven't hacked Pg one single bit (apart from increasing the max identifier name length way back by changing some #define, iirc), I don't really think I'm the right person to do it. :) /Mikael ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Plans for 8.2?
On Mon, Jan 16, 2006 at 09:21:55AM +0100, H.J. Sanders wrote: Thanks for you answer. I've looked for the stats but I could not find it in our 7.4 , but I will look further (perhaps SUSE didn't install them). How did you look? You shouldn't have to install anything extra; statistics collection is built-in to the backend. It's generally not enabled by default, however, so you might have to modify your server configuration (postgresql.conf). See Statistics Collection Configuration in the documentation: http://www.postgresql.org/docs/7.4/interactive/monitoring-stats.html -- Michael Fuhr ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Plans for 8.2?
On Fri, Jan 13, 2006 at 05:30:49PM -0800, Joshua D. Drake wrote: Why would you only recommend Slony? How does it compare to Sequoia or p/cluster? Well p/cluster is not OSS. Sequioa is but is query based and doesn't correctly deal with things like now(). I was speaking directly about OSS replication. Correct me if I'm wrong, but AFAIK Slony is the only OSS replication that isn't statement based, which as Josh mentioned has some serious ramifications. -- 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 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: [GENERAL] Plans for 8.2?
Well p/cluster is not OSS. Sequioa is but is query based and doesn't correctly deal with things like now(). I was speaking directly about OSS replication. Correct me if I'm wrong, but AFAIK Slony is the only OSS replication that isn't statement based, which as Josh mentioned has some serious ramifications. Yes that is correct to my knowledge. Sincerely, Joshua D. Drake -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Plans for 8.2?
I just did a test to see what comes up when I typed replication in the search box at postgresql.org. Got a 503 error. We really need to work on that. Bad enough we don't use Postgres to do the searching. Yes we do. We certainly don't back aspseek with mysql... (No, we don't use the standard version, the one we use is fairly extensively modified) Oh, and I beleive the 503 error is solved. And yes, that definitly could've been handled better. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[GENERAL] Plans for 8.2?
Hello. Just one request that would make the transition from another great database to PostgreSQL a lot easier: SET LOCK MODE TO WAIT n n = the max.time in second to wait. Please? My Christmas present?? For Christmas 2007 I like: statistics about how many sequential scans where have been for a given table. Regards Henk Sanders ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Plans for 8.2?
On Fri, Jan 13, 2006 at 09:30:22AM +0100, H.J. Sanders wrote:
Just one request that would make the transition from another
great database to PostgreSQL a lot easier:
SET LOCK MODE TO WAIT n
n = the max.time in second to wait.
Will statement_timeout suffice?
http://www.postgresql.org/docs/8.1/interactive/runtime-config-client.html
For Christmas 2007 I like:
statistics about how many sequential scans where have been for a given table.
Is pg_stat_{all,sys,user}_tables.seq_scan not what you're looking for?
http://www.postgresql.org/docs/8.1/interactive/monitoring-stats.html
--
Michael Fuhr
---(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: [GENERAL] Plans for 8.2?
On Fri, Jan 13, 2006 at 01:49:02AM -0700, Michael Fuhr wrote: On Fri, Jan 13, 2006 at 09:30:22AM +0100, H.J. Sanders wrote: Just one request that would make the transition from another great database to PostgreSQL a lot easier: SET LOCK MODE TO WAIT n n = the max.time in second to wait. Will statement_timeout suffice? (I'm not implying that statement_timeout is equivalent, I'm just wondering if you might be able to use it in certain circumstances.) -- Michael Fuhr ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Plans for 8.2?
On Thu, Jan 12, 2006 at 07:46:18PM -0500, Tom Lane wrote: * Transaction was committed/aborted/crashed - we have to update pg_clog * if transaction is still marked as running. */ if (!TransactionIdDidCommit(xid) !TransactionIdDidAbort(xid)) TransactionIdAbort(xid); The comment's have to is an overstatement. The transaction would be treated as crashed anyway, it's just that this is a convenient place to make pg_clog a bit cleaner. I'm not real sure why we bother, actually. Because that's what makes PostgreSQL such a reliable product. You follow your intuition and taste and bother doing cleanup even if you cannot immediately tell whether it's *really* needed. Better safe than sorry. Not a bad idea for a database. Karsten (who is storing clinical data in PostgreSQL) -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Plans for 8.2?
In article [EMAIL PROTECTED], Harry Jackson [EMAIL PROTECTED] wrote: % I am not aware of Oracle etc having a seperate company that sells % replication on top of their database although I could be wrong. There's more than one third-party replication offering for Oracle. -- Patrick TJ McPhee North York Canada [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: [GENERAL] Plans for 8.2?
Jeff Trout skrev: Built In Failover/Clustering This won't happen. The community stance, which is a good one is that no single replication solutions fits everyone's needs and therefore we rely out the outside sources. Slony-I, Mammoth Replicator and pgpool being the most popular. Too bad - I think that will keep a lot of potential users from evaluating Pg as a serious alternative. Good or bad, decide for yourself :) Isn't the [expensive db name here]'s replication/failover just an expensive addon? As in if you don't pay for it you don't get it. So we're basically in the same boat as them.. just an add on. we just offer more variety. Not really. The available options for postgresql are simply not as good as what the big databases offer. For some problems the non-transaction master/slave Slony-I is good enough. But to claim it is good enough for all, is like when MySQL claimed nobody really needs transactions. I am a big postgresql fan, and I have several production clusters using DRBD to replicate postgresql databases in an active/failover configuration. But some day I am going to need a cluster that can do active/active, and that day I will be forced to adopt a different database. I will also point out that none of the replication solutions have the same solid reputation as postgresql. As long the postgresql team will not endorse a replication solution, you can not expect people to put the same trust in these solutions as we put into postgresql itself. Oracle do endorse their own replication solution after all. Baldur ---(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: [GENERAL] Plans for 8.2?
On Thu, Jan 12, 2006 at 10:40:40PM +0100, Baldur Norddahl wrote: I will also point out that none of the replication solutions have the same solid reputation as postgresql. As long the postgresql team will not endorse a replication solution, you can not expect people to put the same trust in these solutions as we put into postgresql itself. So you're saying that unless PostgreSQL Core (which I assume you're referring to with postgresql team) endorse a pile of code that they neither wrote, audited nor have any experience with, it won't be good enough for you? I rather they didn't endorse anything they wern't sure of. Replication is hard. There are many replication solutions for Postgres, both multi-master and master/slave and sync/async. I'd rather these products prove themselves than by anyone stamping them Endorsed. Oracle do endorse their own replication solution after all. I suppose they had a hand in writing it too... Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. signature.asc Description: Digital signature
Re: [GENERAL] Plans for 8.2?
Too bad - I think that will keep a lot of potential users from evaluating Pg as a serious alternative. Good or bad, decide for yourself :) Why on earth should that be? Citing Baldur Norddahl (http://archives.postgresql.org/pgsql-general/2006-01/msg00597.php): I will also point out that none of the replication solutions have the same solid reputation as postgresql. As long the postgresql team will not endorse a replication solution, you can not expect people to put the same trust in these solutions as we put into postgresql itself. /Mikael ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Plans for 8.2?
Not really. The available options for postgresql are simply not as good as what the big databases offer. For some problems the non-transaction master/slave Slony-I is good enough. But to claim it is good enough for all, is like when MySQL claimed nobody really needs transactions. Nobody claimed Slony-I is good for all. That is why there are other products out there. Mammoth Replicator (blatant plug and which is a transaction log based replication) for example. I am a big postgresql fan, and I have several production clusters using DRBD to replicate postgresql databases in an active/failover configuration. But some day I am going to need a cluster that can do active/active, and that day I will be forced to adopt a different database. Active, active as in multi-master? I will also point out that none of the replication solutions have the same solid reputation as postgresql. As long the postgresql team will not endorse a replication solution, you can not expect people to put the same trust in these solutions as we put into postgresql itself. That's true enough. Oracle do endorse their own replication solution after all. Well they wrote it, they have to. Joshua D. Drake Baldur ---(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 -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.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: [GENERAL] Plans for 8.2?
Karsten Hilbert [EMAIL PROTECTED] writes: On Thu, Jan 12, 2006 at 07:46:18PM -0500, Tom Lane wrote: The comment's have to is an overstatement. The transaction would be treated as crashed anyway, it's just that this is a convenient place to make pg_clog a bit cleaner. I'm not real sure why we bother, actually. Because that's what makes PostgreSQL such a reliable product. You follow your intuition and taste and bother doing cleanup even if you cannot immediately tell whether it's *really* needed. Well, this is not a correctness issue. If it were, XactLockTableWait would be quite the wrong place for it, because there's no guarantee anyone will ever do XactLockTableWait for any particular transaction ID. In fact, now that I look at it, I'm pretty well convinced this is dead code: we only ever wait for XIDs that are known to have been alive in the recent past, ie, within the lifespan of the current backend. So the case should never occur ... unless possibly in the microseconds before we receive SIGQUIT from the postmaster because the other guy crashed, and in that situation trying to issue a write on pg_clog is probably not the brightest action to be taking anyway. This could easily represent a net minus for reliability, not a plus, if it increases the risk of pg_clog getting corrupted during a crash sequence. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Plans for 8.2?
Active, active as in multi-master? More like a Oracle grid system. 10g. -- Aly S.P Dharshi [EMAIL PROTECTED] A good speech is like a good dress that's short enough to be interesting and long enough to cover the subject ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Plans for 8.2?
Aly Dharshi wrote: Active, active as in multi-master? More like a Oracle grid system. 10g. Heh. Well here is the thing. Oracle has billions of dollars. Plus. 1. We really don't compete against Oracle grid. The people that *need* Oracle grid, are going to buy Oracle grid. 2. We don't need to compete against Oracle grid as nobody else that could be considered competition has it either. 3. We will get there in time but we have more important things to worry about. I would rather us be a 100% solution for 98% of the people then a 100% solution for 2%. Sincerely, Joshua D. Drake -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Plans for 8.2?
On Fri, Jan 13, 2006 at 01:59:19AM -0700, Michael Fuhr wrote: On Fri, Jan 13, 2006 at 01:49:02AM -0700, Michael Fuhr wrote: On Fri, Jan 13, 2006 at 09:30:22AM +0100, H.J. Sanders wrote: Just one request that would make the transition from another great database to PostgreSQL a lot easier: SET LOCK MODE TO WAIT n n = the max.time in second to wait. Will statement_timeout suffice? (I'm not implying that statement_timeout is equivalent, I'm just wondering if you might be able to use it in certain circumstances.) It strikes me that if we had a way to abort a statement on another backend, you could abort anything that's been waiting more than x seconds for a lock via an external process watching pg_locks. Of course, that would be much more cumbersom than SET LOCK MODE TO WAIT n... -- 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Plans for 8.2?
On 1/13/06, Jim C. Nasby [EMAIL PROTECTED] wrote: On Thu, Jan 12, 2006 at 10:36:39AM -0800, Joshua D. Drake wrote: Mikael Carneholm wrote: In terms of statistics we do have statistics and exhaustive logging that can provide you with all of that information. Is there something specific that the information already provided really doesn't give you? Can you give an example query for list all queries executed since 12.00 AM, order by block_reads desc? What I'm aiming for is the ability to turn measuring on, regression test my application, turn measuring off again, and list the most offensive queries executed during the regression test. I know of at least one other DBMS that is capable of this...won't mention which one :) You can use timestamp and one of the duration logging options for this. But AFAIK that won't provide any information on IO used, or even blocks read. Not to mention that parsing the logs is a PITA. There has been announce recently about a project for analizing slow queries: http://archives.postgresql.org/pgsql-announce/2006-01/msg7.php -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Plans for 8.2?
On Fri, Jan 13, 2006 at 03:40:48PM -0600, Jim C. Nasby wrote: It strikes me that if we had a way to abort a statement on another backend, you could abort anything that's been waiting more than x seconds for a lock via an external process watching pg_locks. Of course, that would be much more cumbersom than SET LOCK MODE TO WAIT n... There's pg_cancel_backend(), but a mechanism like you describe seems subject to race conditions: by the time you decide to cancel a query and send the signal, the offending query might have completed and you end up cancelling some subsequent query that just started. -- Michael Fuhr ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Plans for 8.2?
On Fri, Jan 13, 2006 at 03:15:06PM +0100, Mikael Carneholm wrote: Too bad - I think that will keep a lot of potential users from evaluating Pg as a serious alternative. Good or bad, decide for yourself :) Why on earth should that be? Citing Baldur Norddahl (http://archives.postgresql.org/pgsql-general/2006-01/msg00597.php): I will also point out that none of the replication solutions have the same solid reputation as postgresql. As long the postgresql team will not endorse a replication solution, you can not expect people to put the same trust in these solutions as we put into postgresql itself. I'm not really sure what you're looking for here. None of the replication solutions have the same reputation as PostgreSQL itself because they're both newer than PostgreSQL itself and used by a much smaller number of people. If you want to increase the reputation of a replication solution, it's going to take something other than trying to get core to put out some kind of endorsement. Case studies of real-world users is something that would help. Showing what kind of test coverage there is wouldn't hurt. Performance tests would be good. In other words, if promoting replication is important to you, there's plenty of things you can do that will help on that front. But as others have said, the various replication solutions are going to have to stand (or fall) on their own merits. -- 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 5: don't forget to increase your free space map settings
Re: [GENERAL] Plans for 8.2?
On Fri, Jan 13, 2006 at 04:49:02PM -0500, Jaime Casanova wrote: There has been announce recently about a project for analizing slow queries: http://archives.postgresql.org/pgsql-announce/2006-01/msg7.php Sure, but it still means installing an external tool, which requires PHP, which isn't trivial to install in it's own right. And afaik there's still no way to find out how much IO each query did, how much CPU was spent, if any sorts overflowed, etc., etc. -- 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 5: don't forget to increase your free space map settings
Re: [GENERAL] Plans for 8.2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Easy everyone. Let's not bite the newcomers too hard here. 2. Define endorse. Does that mean in the backend? So everyone has to pay the performance penalty even though they won't all use it? Even though no other database system makes you make that compromise? I would presume that at least packaged with PG (in the contrib section) would be a good start. A prominent, east to find link to Slony on the website would help too. I just did a test to see what comes up when I typed replication in the search box at postgresql.org. Got a 503 error. We really need to work on that. Bad enough we don't use Postgres to do the searching. I'd better stop here before I start ranting myself. I didn't expect that 503 error when I started this letter. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200601131734 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFDyCt4vJuQZxSWSsgRAkXZAJ4hvwlENtOxGPh1x+vNu3++izLQCQCgsqCa rW1MUxPxDqYFbdgontgxuwk= =ZlIa -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Plans for 8.2?
On Fri, Jan 13, 2006 at 10:39:06PM -, Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Easy everyone. Let's not bite the newcomers too hard here. 2. Define endorse. Does that mean in the backend? So everyone has to pay the performance penalty even though they won't all use it? Even though no other database system makes you make that compromise? I would presume that at least packaged with PG (in the contrib section) would be a good start. A prominent, east to find link to Slony on the website would help too. Why just Slony? There's at least 2 other free replication solutions I can think of off the top of my head, and I'm sure I'm missing some. And there was rather extensive discussion about contrib on -hackers about 6 months ago. IIRC the decision was that the only reason to put something in contrib was if it was either dependant on specific backend code or if it was targeted for inclusion into the backend. -- 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 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Plans for 8.2?
Jim C. Nasby wrote: On Fri, Jan 13, 2006 at 10:39:06PM -, Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Easy everyone. Let's not bite the newcomers too hard here. 2. Define endorse. Does that mean in the backend? So everyone has to pay the performance penalty even though they won't all use it? Even though no other database system makes you make that compromise? I would presume that at least packaged with PG (in the contrib section) would be a good start. A prominent, east to find link to Slony on the website would help too. Why just Slony? There's at least 2 other free replication solutions I can think of off the top of my head, and I'm sure I'm missing some. Slony is the only free OSS postgreSQL replication solution that I would ever suggest to someone. However if the project is going to start suggesting replication solutions it should suggest all of them. Sincerely, Joshua D. Drake -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Plans for 8.2?
On Fri, Jan 13, 2006 at 10:39:06PM -, Greg Sabino Mullane wrote: I would presume that at least packaged with PG (in the contrib section) would be a good start. A prominent, east to find link to Slony on But in Slony's case, that'd be a regression, not an improvement. It is designed, on purpose, as a bolt-on. That's a feature, not a bug. It allows you to do version upgrades with just a few minutes' switchover time, to begin with, which is something that we don't otherwise have. If we want to fix the in the tarball, or it's not real, we need to continue to make packages easy to install. Nobody thinks that the DBI is some sort of stupid tacky not-ready tool just because every installation of Perl doesn't have it automatically. A -- Andrew Sullivan | [EMAIL PROTECTED] A certain description of men are for getting out of debt, yet are against all taxes for raising money to pay it off. --Alexander Hamilton ---(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: [GENERAL] Plans for 8.2?
On Jan 13, 2006, at 4:00 PM, Joshua D. Drake wrote: Why just Slony? There's at least 2 other free replication solutions I can think of off the top of my head, and I'm sure I'm missing some. Slony is the only free OSS postgreSQL replication solution that I would ever suggest to someone. However if the project is going to start suggesting replication solutions it should suggest all of them. Sincerely, Joshua D. Drake Why would you only recommend Slony? How does it compare to Sequoia or p/cluster? I have to admit that reading about Slony II sounded very good, but it's apparently far off from reality. What's the best solution that would work on OS X Server? Thanks, Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http://www.clickspace.com smime.p7s Description: S/MIME cryptographic signature
Re: [GENERAL] Plans for 8.2?
Sincerely, Joshua D. Drake Why would you only recommend Slony? How does it compare to Sequoia or p/cluster? Well p/cluster is not OSS. Sequioa is but is query based and doesn't correctly deal with things like now(). I was speaking directly about OSS replication. Sincerely, Joshua D. Drake -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[GENERAL] Plans for 8.2?
Hi, I wonder what features other users would like to see in the next version? (8.2) The features I'd (very much) would like to see implemented are: - Top offender statistics In other DBMS:es there are functions that allow you to turn on a sort of monitoring that can tell you, for a period of time: 1) which queries that generated the highest I/O 2) which queries that took the longest time to execute 3) percentage of total time spent on I/O wait, CPU time, etc Statistics like these can be very helpful when it comes to identifying application bottlenecks / areas for improvements. - Materialized views What's the status on the matview project? - Built in failover/clustering There are lots of projects supplying replication/failover/clustering functionality (Slony-I, pgcluster, pgpool etc), but these are non-official in that they do not provide out-of-the box functionality (ie not bundled with a default Pg install) - Analytic/window functions In DBMS:es such as Oracle, there's rank(), dense_rank(), lag(), lead() etc. These functions may(?) be possible to implement using existing/new aggregates. Comments? /Mikael ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Plans for 8.2?
Mikael Carneholm wrote: Hi, I wonder what features other users would like to see in the next version? (8.2) The features I'd (very much) would like to see implemented are: - Top offender statistics In other DBMS:es there are functions that allow you to turn on a sort of monitoring that can tell you, for a period of time: 1) which queries that generated the highest I/O 2) which queries that took the longest time to execute 3) percentage of total time spent on I/O wait, CPU time, etc Statistics like these can be very helpful when it comes to identifying application bottlenecks / areas for improvements. - Materialized views What's the status on the matview project? - Built in failover/clustering There are lots of projects supplying replication/failover/clustering functionality (Slony-I, pgcluster, pgpool etc), but these are non-official in that they do not provide out-of-the box functionality (ie not bundled with a default Pg install) - Analytic/window functions In DBMS:es such as Oracle, there's rank(), dense_rank(), lag(), lead() etc. These functions may(?) be possible to implement using existing/new aggregates. Comments? You should probably review the archives on a lot of these topics. Many of them have been discussed to death :). In terms of statistics we do have statistics and exhaustive logging that can provide you with all of that information. Is there something specific that the information already provided really doesn't give you? Materialized views we have, in a sense but much like updateable views you have to code for it. Built In Failover/Clustering This won't happen. The community stance, which is a good one is that no single replication solutions fits everyone's needs and therefore we rely out the outside sources. Slony-I, Mammoth Replicator and pgpool being the most popular. Analytic/window functions: Get coding man! :) We would love to have them. Sincerely, Joshua D. Drake /Mikael ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Plans for 8.2?
In terms of statistics we do have statistics and exhaustive logging that can provide you with all of that information. Is there something specific that the information already provided really doesn't give you? Can you give an example query for list all queries executed since 12.00 AM, order by block_reads desc? What I'm aiming for is the ability to turn measuring on, regression test my application, turn measuring off again, and list the most offensive queries executed during the regression test. I know of at least one other DBMS that is capable of this...won't mention which one :) Materialized views we have, in a sense but much like updateable views you have to code for it. I think what I'm looking for is MV support out-of-the-box, i.e CREATE MATERIALIZED VIEW foo_mv AS .. Built In Failover/Clustering This won't happen. The community stance, which is a good one is that no single replication solutions fits everyone's needs and therefore we rely out the outside sources. Slony-I, Mammoth Replicator and pgpool being the most popular. Too bad - I think that will keep a lot of potential users from evaluating Pg as a serious alternative. Good or bad, decide for yourself :) Analytic/window functions: Get coding man! :) We would love to have them. Sure - as soon as I'm finished with my 4 other hobby projects. Too many ideas, too little time.. *sigh* :/ /Mikael ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Plans for 8.2?
From the ToDo list... http://www.postgresql.org/docs/faqs.TODO.html * Allow administrators to safely terminate individual sessions either via an SQL function or SIGTERM * Add SQL99 WITH clause to SELECT * Add SQL99 WITH RECURSIVE to SELECT * Create a bitmap of pages that need vacuuming -- output = reverse(moc.enworbbc @ enworbbc) http://cbbrowne.com/info/languages.html Rules of the Evil Overlord #86. I will make sure that my doomsday device is up to code and properly grounded. http://www.eviloverlord.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Plans for 8.2?
Mikael Carneholm wrote: In terms of statistics we do have statistics and exhaustive logging that can provide you with all of that information. Is there something specific that the information already provided really doesn't give you? Can you give an example query for list all queries executed since 12.00 AM, order by block_reads desc? What I'm aiming for is the ability to turn measuring on, regression test my application, turn measuring off again, and list the most offensive queries executed during the regression test. I know of at least one other DBMS that is capable of this...won't mention which one :) You can use timestamp and one of the duration logging options for this. Built In Failover/Clustering This won't happen. The community stance, which is a good one is that no single replication solutions fits everyone's needs and therefore we rely out the outside sources. Slony-I, Mammoth Replicator and pgpool being the most popular. Too bad - I think that will keep a lot of potential users from evaluating Pg as a serious alternative. Good or bad, decide for yourself :) Although that is one thought, the project is fairly good at supporting the various solutions in terms of where and how they exist. Most people that are going to seriously use postgresql are going to do the very easy research to get the right answer they need. Get coding man! :) We would love to have them. Sure - as soon as I'm finished with my 4 other hobby projects. Too many ideas, too little time.. *sigh* :/ Perhaps you should drop the other 4 and concentrate on the important one ;) Joshua D. Drake /Mikael ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Plans for 8.2?
Chris Browne schrieb: From the ToDo list... http://www.postgresql.org/docs/faqs.TODO.html * Allow administrators to safely terminate individual sessions either via an SQL function or SIGTERM I thought this already works? At least I'm doing so when I need ... (SIGTERM) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Plans for 8.2?
Tino Wildenhain [EMAIL PROTECTED] writes: * Allow administrators to safely terminate individual sessions either via an SQL function or SIGTERM I thought this already works? At least I'm doing so when I need ... (SIGTERM) The key word there is safely. We don't have a lot of trust in SIGTERM'ing individual backends (as opposed to shutting down the whole cluster at once, which is a well-tested code path). See the archives. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Plans for 8.2?
On Jan 12, 2006, at 1:36 PM, Joshua D. Drake wrote: Built In Failover/Clustering This won't happen. The community stance, which is a good one is that no single replication solutions fits everyone's needs and therefore we rely out the outside sources. Slony-I, Mammoth Replicator and pgpool being the most popular. Too bad - I think that will keep a lot of potential users from evaluating Pg as a serious alternative. Good or bad, decide for yourself :) Isn't the [expensive db name here]'s replication/failover just an expensive addon? As in if you don't pay for it you don't get it. So we're basically in the same boat as them.. just an add on. we just offer more variety. -- Jeff Trout [EMAIL PROTECTED] http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(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: [GENERAL] Plans for 8.2?
Jeff Trout [EMAIL PROTECTED] writes: Isn't the [expensive db name here]'s replication/failover just an expensive addon? As in if you don't pay for it you don't get it. So we're basically in the same boat as them.. just an add on. we just offer more variety. Well, [cheap and crappy open-source db name here]'s replication is built in, but we already know we don't want to take them as an example. :) -Doug ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Plans for 8.2?
On 1/12/06, Jeff Trout [EMAIL PROTECTED] wrote: On Jan 12, 2006, at 1:36 PM, Joshua D. Drake wrote: Built In Failover/Clustering This won't happen. The community stance, which is a good one is that no single replication solutions fits everyone's needs and therefore we rely out the outside sources. Slony-I, Mammoth Replicator and pgpool being the most popular. Too bad - I think that will keep a lot of potential users from evaluating Pg as a serious alternative. Good or bad, decide for yourself :) Isn't the [expensive db name here]'s replication/failover just an expensive addon? As in if you don't pay for it you don't get it. So we're basically in the same boat as them.. just an add on. we just offer more variety. Not really. The entire company of [expensive DB name here] is at the end of the phone[0]. Taking Oracle as an example. I am not aware of Oracle etc having a seperate company that sells replication on top of their database although I could be wrong. The other thing is that Oracle is supported by various platforms etc and that support will include their replication or clustering offering. Sun has offered to support PostgreSQL just recently but have they offered to support any of the replication offerings? I would hardly say we are in the same boat just because we have bolt on replication. -- Harry http://www.hjackson.org http://www.uklug.co.uk [0] I am not suggesting that this improves support although it does improve the appearance of support. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Plans for 8.2?
[EMAIL PROTECTED] (Mikael Carneholm) writes: Built In Failover/Clustering This won't happen. The community stance, which is a good one is that no single replication solutions fits everyone's needs and therefore we rely out the outside sources. Slony-I, Mammoth Replicator and pgpool being the most popular. Too bad - I think that will keep a lot of potential users from evaluating Pg as a serious alternative. Good or bad, decide for yourself :) Why on earth should that be? What serious alternative to PostgreSQL actually includes built-in failover or clustering? For Oracle, it is a separate add-on product licensed separately. Ditto for DB2. The same is likely the case for Informix and others. -- (format nil [EMAIL PROTECTED] cbbrowne acm.org) http://cbbrowne.com/info/x.html Let's face it -- ASCII text is a far richer medium than most of us deserve. -- Scott McNealy ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Plans for 8.2?
Tom Lane [EMAIL PROTECTED] wrote The key word there is safely. We don't have a lot of trust in SIGTERM'ing individual backends (as opposed to shutting down the whole cluster at once, which is a well-tested code path). See the archives. Maybe related question: is the code below in XactLockTableWait() related to SIGQUIT? /* * Transaction was committed/aborted/crashed - we have to update pg_clog * if transaction is still marked as running. */ if (!TransactionIdDidCommit(xid) !TransactionIdDidAbort(xid)) TransactionIdAbort(xid); I interpret that if a quickdie or crash happens, then other backends may still run for a while, so it is important to mark related transaction abort. Or there is some other more obvious reason for that? Regards, Qingqing ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Plans for 8.2?
Qingqing Zhou [EMAIL PROTECTED] writes: Maybe related question: is the code below in XactLockTableWait() related to SIGQUIT? No. /* * Transaction was committed/aborted/crashed - we have to update pg_clog * if transaction is still marked as running. */ if (!TransactionIdDidCommit(xid) !TransactionIdDidAbort(xid)) TransactionIdAbort(xid); The comment's have to is an overstatement. The transaction would be treated as crashed anyway, it's just that this is a convenient place to make pg_clog a bit cleaner. I'm not real sure why we bother, actually. regards, tom lane ---(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
