Re: [HACKERS] Documentation epub format
The table of contents too much detailed, so it is long and slow to scan, and there is no clear shortcut. Flipping pages in the documentation takes ages (well, close to one second or more if I flip a few pages). Do not try "search". EPUB is essentially a zip file with per-section simplified HTML files. So any device that can render simple web pages should be able to handle that with ease. What I think iBooks is doing is it internally pre-renders all the pages in order to be able to attach page numbers to all the table of contents entries. I suspect other readers that don't do that will be able to handle this better. Indeed, iBooks computes page numbers, which mean processing the whole contents. That said, I think trimming down the table of contents nesting depth might be worth checking into for this output format. That at least would be a relief. The TOC on iBooks is shown as a very long scrolling window, without collapsable parts. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Documentation epub format
This seems to suggest that instead of generating one large ebook, the build should generate a set of ebooks, say one for each part. At the minimum, a less detailed toc could be more usable and help navigate the huge contents. Once upon a time we had multiple books as documentation, then at some point we merged them. It was quite a few years ago. I would agree at this point that we need to consider breaking them up again. The documentation is unwieldy. PostgreSQL documentation in PDF seemed quite usable on the same ipad, so maybe there is no unique answer. I like the principle and simplicity of "one" document to move around, so sticking to that if possible seems better. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Documentation epub format
On Thu, May 02, 2013 at 03:42:33AM -0400, Andrew Dunstan wrote: > > On 05/01/2013 11:36 PM, Gavin Flower wrote: > >On 02/05/13 15:23, Peter Eisentraut wrote: > >>On Wed, 2013-05-01 at 18:27 +0200, Fabien COELHO wrote: > >>>I must admit that there is a bit of a disappointement as far as the > >>>user experience is concerned: the generated file is barely usable on > >>>an iPad2 with the default iBooks reader, which was clearly not > >>>designed for handling a "4592" pages book (from its point of view). > >>Well, clearly there are mainstream books that have 1000 pages, so it > >>ought to be designed for that. It's not clear to me then why it > >>necessarily must fail at 4000 pages. I think you might want to run some > >>experiments to see what the reader can handle before we start doing > >>anything. > >> > >> > >There might be something silly in some eReaders, like reserving 12 > >bits for page numbers internally - as 'no one will ever want a > >book with more than 4095 pages!'? > > My ancient Sony PRS-505 e-reader has the epub paginated at 5200 > pages, and it seems to work just fine, if a bit slowly. > > It's possibly worth noting that the epub is about 1.5 times the size > of that for War and Peace. At least ours doesn't start out like this: Eh bien, mon prince. Gênes et Lueques ne sont plus que des apanages, des поместья, de la famille Buonaparte. Non, je vous préviens que si vous ne me dites pas que nous avons la guerre, si vous vous permettez encore de pallier toutes les infamies, toutes les atrocités de cet Antichrist (ma parole, j’y crois) — je ne vous connais plus, vous n’êtes plus mon ami, vous n’êtes plus мой верный раб, comme vous dites. Ну, здравствуйте, здравствуйте. Je vois que je vous fais peur, садитесь и рассказывайте. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Documentation epub format
On 03/05/13 15:16, Peter Eisentraut wrote: On Wed, 2013-05-01 at 18:27 +0200, Fabien COELHO wrote: The table of contents too much detailed, so it is long and slow to scan, and there is no clear shortcut. Flipping pages in the documentation takes ages (well, close to one second or more if I flip a few pages). Do not try "search". EPUB is essentially a zip file with per-section simplified HTML files. So any device that can render simple web pages should be able to handle that with ease. What I think iBooks is doing is it internally pre-renders all the pages in order to be able to attach page numbers to all the table of contents entries. I suspect other readers that don't do that will be able to handle this better. That said, I think trimming down the table of contents nesting depth might be worth checking into for this output format. I don't think that you don't need to trim down the nesting depth in pdf, as the table of contents can be displayed in a tree structure, and you only need to expand branches as far you need. I would have assumed ePub would have the same facility, or am I mistaken? Cheers, Gavin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Documentation epub format
On Wed, 2013-05-01 at 18:27 +0200, Fabien COELHO wrote: > The table of contents too much detailed, so it is long and slow to > scan, and there is no clear shortcut. Flipping pages in the > documentation takes ages (well, close to one second or more if I flip > a few pages). Do not try "search". EPUB is essentially a zip file with per-section simplified HTML files. So any device that can render simple web pages should be able to handle that with ease. What I think iBooks is doing is it internally pre-renders all the pages in order to be able to attach page numbers to all the table of contents entries. I suspect other readers that don't do that will be able to handle this better. That said, I think trimming down the table of contents nesting depth might be worth checking into for this output format. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
Karol Trzcionka writes: > It will not solve the problems: > 1. How to access to old rows if the table is named "BEFORE"? The user can simply choose to use a different table alias, as Andres explained upthread. If any table's active alias is "before" (or "after"), we just don't activate the corresponding implicit alias. > 2. Should AFTER for DELETE and BEFORE for INSERT be allowed? If yes what > should they return? These cases should certainly fail. Now, IMO there's no very good reason to alter the behavior at all for INSERT/DELETE; only UPDATE has an issue here. But if we were going to support the extra aliases in those commands, only the ones that actually make sense should be allowed. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] pgbench --throttle (submission 4)
Hi, It would be better to submit updated versions of a patch on the email thread it is dedicated to and not create a new thread so as people can easily follow the progress you are doing. Thanks, -- Michael
Re: [HACKERS] \watch stuck on execution of commands returning no tuples
On Thu, May 2, 2013 at 11:01 PM, Tom Lane wrote: > Michael Paquier writes: > > Hi all, > > When testing \watch, I noticed that process waits indefinitely when > > executing it with a DDL or a DML. > > For example: > > postgres=# CREATE TABLE aa (a int); > > postgres=# ANALYSE aa \watch 10 > > -- Process waiting here > > It's not "waiting", it's doing the ANALYZE once every ten seconds, > just like you told it to. > > Perhaps it'd be a good idea to emit the command tag on receiving a > non-tuple-bearing result, just to make this more obvious. > Yes, the command tag would be a good idea, combined with the watch time that other commands returning tuples have, giving something like that: Watch every 2sFri May 3 10:01:04 2013 $TAG Regards, -- Michael
Re: [HACKERS] Recovery target 'immediate'
On Fri, May 3, 2013 at 8:56 AM, Bruce Momjian wrote: > On Thu, May 2, 2013 at 09:31:03AM +0200, Magnus Hagander wrote: > > Actually, there is - I hear it quite often from people not so > > experienced in PostgreSQL. Though in fairness, I'm not entirely sure > > the new syntax would help - some of those need a tool to do it for > > them, really (and such tools exist, I believe). > > > > That said, there is one property that's very unclear now and that's > > that you can only set one of recovery_target_time, recovery_target_xid > > and recovery_target_name. But they can be freely combined with > > recovery_target_timeline and recovery_target_inclusive. That's quite > > confusing. > > > > > > > > > This changes the existing API which will confuse people that know it > > > and invalidate everything written in software and on wikis as to how > > > to do it. That means all the "in case of fire break glass" > > > instructions are all wrong and need to be rewritten and retested. > > > > Yes, *that* is the main reason *not* to make the change. It has a > > pretty bad cost in backwards compatibility loss. There is a gain, but > > I don't think it outweighs the cost. > > So, is there a way to add this feature without breaking the API? > Yes, by adding a new parameter exclusively used to control this feature, something like recovery_target_immediate = 'on/off'. -- Michael
Re: [HACKERS] Remaining beta blockers
On Thu, May 2, 2013 at 02:20:15PM -0700, Kevin Grittner wrote: > > Yes, pg_upgrade is never going to write to data pages as that > > would be slow and prevent the ability to roll back to the > > previous cluster on error. > > The only person who has suggested anything which would require that > is Andres, who suggests adding a metadata page to the front of the > heap to store information on whether the matview is populated. I > think it is the direct opposite of what Tom is suggesting, and has > too many issues to be considered at this time. > > Nobody has proposed how the technique currently used creates a > pg_upgrade hazard now or in some future release where we provide a > way for recovery to put the information into the catalog. I have > gone into more detail on this earlier on this thread. I was more thinking of the idea of having some status on the first page that might need to change in a future release. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Recovery target 'immediate'
On Thu, May 2, 2013 at 09:31:03AM +0200, Magnus Hagander wrote: > Actually, there is - I hear it quite often from people not so > experienced in PostgreSQL. Though in fairness, I'm not entirely sure > the new syntax would help - some of those need a tool to do it for > them, really (and such tools exist, I believe). > > That said, there is one property that's very unclear now and that's > that you can only set one of recovery_target_time, recovery_target_xid > and recovery_target_name. But they can be freely combined with > recovery_target_timeline and recovery_target_inclusive. That's quite > confusing. > > > > > This changes the existing API which will confuse people that know it > > and invalidate everything written in software and on wikis as to how > > to do it. That means all the "in case of fire break glass" > > instructions are all wrong and need to be rewritten and retested. > > Yes, *that* is the main reason *not* to make the change. It has a > pretty bad cost in backwards compatibility loss. There is a gain, but > I don't think it outweighs the cost. So, is there a way to add this feature without breaking the API? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Recovery target 'immediate'
On Thu, May 2, 2013 at 09:04:20AM +0100, Simon Riggs wrote: > If we feel strongly about user interface design problems we should > treat them the same way we treat performance issues. Profile to > identify problem areas, analyze problems in those areas and suggest > solutions, then make tests to check that the new interface genuinely > works better than the old. That is proper UI improvement, not just > knee jerk reactions. I am not sure if you are serious or now, but for me, email discussion is sufficient. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] \watch stuck on execution of commands returning no tuples
On Thu, May 2, 2013 at 10:01:28AM -0400, Tom Lane wrote: > Michael Paquier writes: > > Hi all, > > When testing \watch, I noticed that process waits indefinitely when > > executing it with a DDL or a DML. > > For example: > > postgres=# CREATE TABLE aa (a int); --> > > postgres=# ANALYSE aa \watch 10 --- > > -- Process waiting here OK, what other database supports British spelling of commands? Can we call this a compatibility feature. ;-) The feature has been there since 2000: commit ebe0b236909732c75d665c73363bd4ac7a7aa138 Author: Bruce Momjian Date: Wed Nov 8 21:28:06 2000 + Add ANALYSE spelling of ANALYZE for vacuum. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should pg_upgrade use --quote-all-identifiers?
On Tue, Apr 30, 2013 at 07:55:33PM -0400, Tom Lane wrote: > Seems like this might be a good idea to avoid the type of failure > exhibited in bug #8128. We don't care too much about the readability > of the dump script created during an upgrade, so it's hard to see a > downside. Fine with me. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 Beta1 status report
On Thu, May 2, 2013 at 03:03:58PM -0700, Jeff Janes wrote: > Some suggestions, perhaps just based on my preference for verbosity: > > > > Add cache of local locks (Jeff Janes) > > > > This speeds lock release at statement completion in transactions > that hold many locks; it is particularly useful for pg_dump. > > > > I think this is equally important for restoration of dumps, if the restoration > is run all in one transaction. (Making the dump and restoring it have similar > locking and unlocking patterns) Do you have proposed wording? I can't say just dump/restore as it only helps with _logical_ dump and _logical_ restore, and we don't have a clear word for logical restore, as it could be pg_restore or piped into psql. We could do: that hold many locks; it is particularly useful for pg_dump and restore. but "restore" seems very vague. > > Split pgstat file in per-database and global files (Tomas Vondra) > > > > This reduces the statistics management read and write overhead. > > > > Should be "split pgstat file into", not "split pgstat file in" That one was easy, fixed. > Also, should it mention that the overhead reduction is particular to when a > cluster has a large number of databases? Well, if you have just two databases with many tables, it still helps. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] high io BUT huge amount of free memory
On 2013-05-02 16:13:42 -0500, Shaun Thomas wrote: > On 05/02/2013 12:04 PM, Josh Berkus wrote: > Yeah, this is why I want to go to Linux Plumbers this year. The > Kernel.org engineers are increasingly doing things which makes Linux > unsuitable for applications which depend on the filesystem. Uh. Yea. > >There is a good, but sad, reason for this: IBM and Oracle and their > >partners are the largest employers of people hacking on core Linux > >memory/IO functionality, and both of those companies use DirectIO > >extensively in their products. > > I never thought of that. Somehow I figured all the Redhat engineers would > somehow counterbalance that kind of influence. I think the reason you never thought of that is that it doesn't have much to do with reality. Calling the linux direct io implemention well maintained and well performing is a rather bad joke. Sorry, I can't find a friendlier description. And no, thats not my opinion. That's the opinion of the people maintaining it. Google it if you don't believe me. Also, IBM and Oracle - which afaik was never really up there - haven't been at top of the contributing companies list for a while. Like several years. I can only repeat myself: The blame game against the linux kernel played here on the lists is neither an accurate description of reality nor helpful. The only two recent occasions where I can remember postgres people reaching out to lkml the reported problems got fixed in an reasonable amount of time. One was the lseek(2) scalability issue discovered by Robert which, after some prodding by yours truly, got solved entirely by Andi Kleen and some major performance regression in an development (!) kernel that was made visible by pg that got fixed before the final release was made. Note well that they *do* regularly test development kernels with various version of postgres. We don't do the reverse in any way that is remotely systematic. Report the problems you find instead of whining! And remember when you measure the performance of a several year old kernel how we react when somebody complains too loudly about performance problems in 8.3. Yes it sucks majorly to update your kernel. But quite often its far easier than updating the postgres major version. And way easier to roll back. > But that brings up an interesting question. How hard / feasible would it be > to add DIO functionality to PG itself? I don't think there is too much chance of that - but I also don't really see the point in trying to do it. We should start by improving postgres buffer writeout which isn't that great, especially with big shared buffers. We would have to invest quite a lot of work in how our buffering and writeout works to make DIO perform nicely. > I've already heard chatter (Robert > Haas?) about converting the shared memory allocation to an anonymous block, > so could we simultaneously open up a DMA relationship? We've got that in 9.3 which is absolutely fabulous! But that's not related to doing DMA which you cannot (and should not!) do from userspace. I hate to be so harsh, but this topic has been getting on my nerves for quite a while now and its constantly getting worse. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 Beta1 status report
On Thu, May 2, 2013 at 02:09:21PM -0700, Josh Berkus wrote: > > > > > > > Add a Postgres foreign data wrapper contrib module (Shigeru > > Hanada, KaiGai Kohei) > > > > > > > > This foreign data wrapper allows writes; potentially other > > foreign data wrappers can now support writes. > > > > > > > > Are you saying split up this into two items? > > Yes, because it's two separate features. > > I know Andrew plans to have a writeable Redis FDW before 9.3 is > released, for one. OK, I have split them apart: Allow write-enabled foreign data wrappers to support writes (KaiGai Kohei) Add a Postgres foreign data wrapper contrib module (Shigeru Hanada) This foreign data wrapper allows writes. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] matview niceties: pick any two of these three
> Tom wants to ditch (2) to allow the others. Robert wants to ditch > (1) to allow the others. I want to ditch (3) to allow the others. > Andres wants (3) and has not expressed an opinion on which he would > prefer to give up to get it. I believe Josh Berkus has mentioned > how useful he thinks both (1) and (2) would be, without really > commenting on (3). As I understand it, we don't currently have any mechanism in Postgres which would cause allocated-but-empty pages. That we *might* have such a thing in 9.4 doesn't seem like a sufficient obstacle; we also might not. Further, I don't think that pg_upgrade is really a red card here. Matviews will be a new feature for 9.3. If we end up having to say "if you use pg_upgrade to upgrade to 9.4, you will need to rebuild your matviews afterwards", then that's what happens. People are used to some wonkiness in new features, and at this point the majority of our users don't use pg_upgrade. So, yes, I'd vote for (1) and (2) over (3), if that's the options which make sense. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 9.3 Beta1 status report
On Sat, Apr 20, 2013 at 10:02 PM, Bruce Momjian wrote: I am not sure if Tom shared yet, but we are planning to package 9.3 > beta1 on April 29, with a release on May 2. Those dates might change, > but that is the current plan. I have completed a draft 9.3 release > notes, which you can view here: > http://momjian.us/pgsql_docs/release-9-3.html > I will be working on polishing them for the next ten days, so any > feedback, patches, or commits are welcome. I still need to add lots of > SGML markup. Some suggestions, perhaps just based on my preference for verbosity: Add cache of local locks (Jeff Janes) This speeds lock release at statement completion in transactions that hold many locks; it is particularly useful for pg_dump. I think this is equally important for restoration of dumps, if the restoration is run all in one transaction. (Making the dump and restoring it have similar locking and unlocking patterns) Split pgstat file in per-database and global files (Tomas Vondra) This reduces the statistics management read and write overhead. Should be "split pgstat file into", not "split pgstat file in" Also, should it mention that the overhead reduction is particular to when a cluster has a large number of databases? Cheers, Jeff
[HACKERS] matview niceties: pick any two of these three
Tom has refactored where and how certain parts of the work get done for materialized views, reducing issues with modularity violations. I have been and will continue to review his changes to better understand how the pieces of the code fit together, so hopefully he won't need to do so much with future contributions. He has not, so far, changed functionality or the regression tests -- although he has complained about things, of which the below is the all of what remains as an issue for him as far as I know. I may have missed something; if so, it would be great to be reminded of what. What remains is a choice between three alternatives on which no consensus has been reached. There are three things that, as fas as I can tell, *everyone* agrees would be nice to be true about the matview implementation for 9.3, but it does not seem feasible to have more than two: (1) The ability to count on the results from a query which references a matview to reflect valid data from *some* point in time. (2) The ability to create unlogged materialized views. (3) The ability to consider a zero-length matview heap and a matview heap with allocated-but-empty pages as logically identical. Tom wants to ditch (2) to allow the others. Robert wants to ditch (1) to allow the others. I want to ditch (3) to allow the others. Andres wants (3) and has not expressed an opinion on which he would prefer to give up to get it. I believe Josh Berkus has mentioned how useful he thinks both (1) and (2) would be, without really commenting on (3). I am convinced that we can solve (3) in a later release without any significant impact on those already using matviews, including unlogged ones. Tom and Robert have suggested that the current implementation would paint us into a corner or pose a pg_upgrade hazard, without any clear indication of the mechanism of the problem. The logjam has caused me to hold back on finishing up the direction I prefer, for fear of conflicts with other work that someone else may be trying to do. Given that time is short, I'm going to apply the patch which inserts five lines (two of them comment lines) on the basis that at least the way that is currently implemented will have no known bugs, and it's just not that much to rip back out if we reach consensus on another direction. How to we resolve this impasse? -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
W dniu 02.05.2013 23:34, Gavin Flower pisze: > I prefer 'PRIOR & 'AFTER' as the both have the same length > - but perhaps that is just me! :-) I think it doesn't matter at now because PRIOR has the same problems as BEFORE ;) Regards, Karol
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
On 03/05/13 04:52, David Fetter wrote: On Thu, May 02, 2013 at 06:28:53PM +0200, Andres Freund wrote: On 2013-05-02 12:23:19 -0400, Tom Lane wrote: Marko Tiikkaja writes: What I'm more interested in is: how can we make this feature work in PL/PgSQL where OLD means something different? That's a really good point: if you follow this approach then you're creating fundamental conflicts for use of the feature in trigger functions or rules, which will necessarily have conflicting uses of those names. Yeah, we could define scoping rules such that there's an unambiguous interpretation, but then the user is just out of luck if he wants to reference the other definition. (This problem is probably actually worse if you implement with reserved words rather than aliases.) I'm thinking it would be better to invent some other notation for access to old-row values. prior/after? Both are unreserved keywords atm and it seems far less likely to have conflicts than new/old. BEFORE/AFTER seems more logical to me. Yes, those words both have meaning in, for example, a trigger definition, but they're clearly separable by context. Yay, bike-shedding! Cheers, David. I prefer 'PRIOR & 'AFTER' as the both have the same length - but perhaps that is just me! :-) Cheers, Gavin
Re: [HACKERS] Remaining beta blockers
Bruce Momjian wrote: > Robert Haas wrote: >> Kevin Grittner wrote: > What is a real problem or risk with using this mechanism > until we engineer something better? What problems with > converting to a later major release does anyone see? Well, it's a pg_upgrade hazard, if nothing else, isn't it? >>> >>> I don't think so. What do you see as a problem? >> >> pg_upgrade only handles changes in catalog state, not on-disk >> representation. If the on-disk representation of an >> non-scannable view might change in a future release, it's a >> pg_upgrade hazard. > > Yes, pg_upgrade is never going to write to data pages as that > would be slow and prevent the ability to roll back to the > previous cluster on error. The only person who has suggested anything which would require that is Andres, who suggests adding a metadata page to the front of the heap to store information on whether the matview is populated. I think it is the direct opposite of what Tom is suggesting, and has too many issues to be considered at this time. Nobody has proposed how the technique currently used creates a pg_upgrade hazard now or in some future release where we provide a way for recovery to put the information into the catalog. I have gone into more detail on this earlier on this thread. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] high io BUT huge amount of free memory
On 05/02/2013 12:04 PM, Josh Berkus wrote: There is a good, but sad, reason for this: IBM and Oracle and their partners are the largest employers of people hacking on core Linux memory/IO functionality, and both of those companies use DirectIO extensively in their products. I never thought of that. Somehow I figured all the Redhat engineers would somehow counterbalance that kind of influence. But that brings up an interesting question. How hard / feasible would it be to add DIO functionality to PG itself? I've already heard chatter (Robert Haas?) about converting the shared memory allocation to an anonymous block, so could we simultaneously open up a DMA relationship? -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604 312-676-8870 stho...@optionshouse.com __ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 Beta1 status report
> > > Add a Postgres foreign data wrapper contrib module (Shigeru > Hanada, KaiGai Kohei) > > > > This foreign data wrapper allows writes; potentially other > foreign data wrappers can now support writes. > > > > Are you saying split up this into two items? Yes, because it's two separate features. I know Andrew plans to have a writeable Redis FDW before 9.3 is released, for one. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 Beta1 status report
On Sat, Apr 27, 2013 at 05:29:51PM -0700, Josh Berkus wrote: > Bruce, > > So here's my draft list of "Major Enhancements" for the relase notes: > > * Writeable Foreign Tables > * pgsql_fdw driver for federation of PostgreSQL databases > * Automatically updatable VIEWs > * MATERIALIZED VIEW declaration > * LATERAL JOINs > * Additional JSON constructor and extractor functions > * Indexed regular expression search > * Disk page checksums to detect filesystem failures > * Streaming-only remastering of replicas > * Performance and locking improvements for Foreign Key locks > * Parallel pg_dump for faster backups > * Directories for configuration files > * pg_isready database connection checker > * COPY FREEZE for reduced IO bulk loading > * User-defined background workers for automating database tasks > * Recursive view declaration > > I note that the first one I'm leading off with actually isn't included > in your release notes. So please add it: > > Allow foreign data wrappers to accept writes > Foreign data sources can now be written to, > as well as read, provided that the FDW driver > supports it. Well, this is the text I have now, which was suggested to me: Add a Postgres foreign data wrapper contrib module (Shigeru Hanada, KaiGai Kohei) This foreign data wrapper allows writes; potentially other foreign data wrappers can now support writes. Are you saying split up this into two items? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
W dniu 02.05.2013 20:45, Tom Lane pisze: > David Fetter writes: >> Maybe we can make BEFORE and AFTER implied aliases rather than >> keywords. What say? > Well, they still have to be unreserved keywords for their use in > trigger-related commands, but as far as this feature is concerned > I think they're best off being handled as automatically-supplied > aliases. IOW the patch needn't touch gram.y at all. Well... the syntax which wouldn't conflict with Pl/PgSQL is (draft): INSERT INTO foo ... RETURNING AFTER.* UPDATE foo SET ... RETURNING AFTER.*, BEFORE.* DELETE FROM foo ... RETURNING BEFORE.* It will not solve the problems: 1. How to access to old rows if the table is named "BEFORE"? 2. Should AFTER for DELETE and BEFORE for INSERT be allowed? If yes what should they return? I mean: what should be result of: INSERT INTO foo ... RETURNING BEFORE.* and DELETE FROM foo ... RETURNING AFTER.* ? The best summarize of dropping NEW/OLD keywords for this proposal was proposed while IRC meeting: create or replace function ft1(integer) returns integer language plpgsql as $f$ <> declare r rt1; begin select 1 as a into r; update rt1 r set a = a + 1 returning XXX into r; raise notice 'r = %', r; return null; end; $f$; Regards, Karol Trzcionka -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
Karol Trzcionka writes: > What do you think about function- or cast-like syntax. I mean: > RETURNING OLD(foo.bar) > or RETURNING OLD(foo).bar > or RETURNING (foo::OLD).bar ? > I think none of them should conflict with any other statements. I think you'll find those alternatives are at least as ugly to implement as they are to look at ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
David Fetter writes: > Maybe we can make BEFORE and AFTER implied aliases rather than > keywords. What say? Well, they still have to be unreserved keywords for their use in trigger-related commands, but as far as this feature is concerned I think they're best off being handled as automatically-supplied aliases. IOW the patch needn't touch gram.y at all. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
Sent from my iPad On 03-May-2013, at 0:07, David Fetter wrote: > On Thu, May 02, 2013 at 01:40:59PM -0400, Tom Lane wrote: >> David Fetter writes: >>> On Thu, May 02, 2013 at 06:28:53PM +0200, Andres Freund wrote: prior/after? Both are unreserved keywords atm and it seems far less likely to have conflicts than new/old. >> >>> BEFORE/AFTER seems more logical to me. >> >> Works for me. >> >>regards, tom lane > > Maybe we can make BEFORE and AFTER implied aliases rather than > keywords. What say? > > I agree.Overall,I like the concept. Regards, Atri -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
On Thu, May 02, 2013 at 01:40:59PM -0400, Tom Lane wrote: > David Fetter writes: > > On Thu, May 02, 2013 at 06:28:53PM +0200, Andres Freund wrote: > >> prior/after? Both are unreserved keywords atm and it seems far less > >> likely to have conflicts than new/old. > > > BEFORE/AFTER seems more logical to me. > > Works for me. > > regards, tom lane Maybe we can make BEFORE and AFTER implied aliases rather than keywords. What say? Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgbench --startup option
I've just done a quick review of the source, as I've been hacking in pgbench myself. I think that the feature makes sense. About the details of the patch: (1) Some changes in the patch are unrelated to the purpose of the patch (e.g. spacing changes, error message...), and should be removed? (2) Instead adding a new function, I would suggest to modify the existing one with an added argument, which would be ignored when NULL is passed. (3) I'm not sure of the behavior of the feature. What if two statements are required, should it not be able to handle multiple --startup specifications, say with an array instead of a scalar? (4) C style: there is no need to put a ";" after "}". (5) In the documentation, other options do not put a "=" sign between the option and its argument, although it is also accepted. Have a nice day, -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [PATCH] add long options to pgbench (submission 1)
This is mostly for reference to the next commitfest.
This very minor patch adds a corresponding long option to all short (one
letter) options of pgbench. In particular for connection options there is
now --host --username --port options similar to the "psql" client.
While I was at developing some small extensions to pgbench, ISTM that I
could do that without much effort.
Note that I'm not so sure about whether to chose singular or plural long
option names.
--
Fabien.diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c
index bc01f07..7109305 100644
--- a/contrib/pgbench/pgbench.c
+++ b/contrib/pgbench/pgbench.c
@@ -2080,6 +2080,30 @@ int
main(int argc, char **argv)
{
static struct option long_options[] = {
+ /* long/short named options*/
+ {"initialize", no_argument, NULL, 'i'},
+ {"host", required_argument, NULL, 'h'},
+ {"no-vacuum", no_argument, NULL, 'n'},
+ {"vacuum-all", no_argument, NULL, 'v'},
+ {"port", required_argument, NULL, 'p'},
+ {"debug", no_argument, NULL, 'd'},
+ {"select-only", no_argument, NULL, 'S'},
+ {"skip-some-update", no_argument, NULL, 'N'},
+ {"client", required_argument, NULL, 'c'},
+ {"jobs", required_argument, NULL, 'j'},
+ {"connect", no_argument, NULL, 'C'},
+ {"report-latencies", no_argument, NULL, 'r'},
+ {"scale", required_argument, NULL, 's'},
+ {"transactions", required_argument, NULL, 't'},
+ {"time", required_argument, NULL, 'T'},
+ {"username", required_argument, NULL, 'U'},
+ {"log", no_argument, NULL, 'l'},
+ {"quiet-log", no_argument, NULL, 'q'},
+ {"file", required_argument, NULL, 'f'},
+ {"define", required_argument, NULL, 'D'},
+ {"fill-factor", required_argument, NULL, 'F'},
+ {"query-mode", required_argument, NULL, 'M'},
+ /* long-named only options */
{"foreign-keys", no_argument, &foreign_keys, 1},
{"index-tablespace", required_argument, NULL, 3},
{"tablespace", required_argument, NULL, 2},
diff --git a/doc/src/sgml/pgbench.sgml b/doc/src/sgml/pgbench.sgml
index 79b4baf..bc84ec0 100644
--- a/doc/src/sgml/pgbench.sgml
+++ b/doc/src/sgml/pgbench.sgml
@@ -150,6 +150,7 @@ pgbench options dbname
-i
+ --initialize
Required to invoke initialization mode.
@@ -159,6 +160,7 @@ pgbench options dbname
-n
+ --no-vacuum
Perform no vacuuming after initialization.
@@ -168,6 +170,7 @@ pgbench options dbname
-F fillfactor
+ --fill-factor fillfactor
Create the pgbench_accounts,
@@ -180,6 +183,7 @@ pgbench options dbname
-s scale_factor
+ --scale scale_factor
Multiply the number of rows generated by the scale factor.
@@ -196,6 +200,7 @@ pgbench options dbname
-q
+ --quiet-log
Switch logging to quiet mode, producing only one progress message per 5
@@ -259,6 +264,7 @@ pgbench options dbname
-c clients
+ --client clients
Number of clients simulated, that is, number of concurrent database
@@ -269,6 +275,7 @@ pgbench options dbname
-C
+ --connect
Establish a new connection for each transaction, rather than
@@ -280,6 +287,7 @@ pgbench options dbname
-d
+ --debug
Print debugging output.
@@ -289,6 +297,7 @@ pgbench options dbname
-D varname=value
+ --define varname=value
Define a variable for use by a custom script (see below).
@@ -299,6 +308,7 @@ pgbench options dbname
-f filename
+ --file filename
Read transaction script from filename.
@@ -311,6 +321,7 @@ pgbench options dbname
-j threads
+ --jobs threads
Number of worker threads within pgbench.
@@ -324,6 +335,7 @@ pgbench options dbname
-l
+ --log
Write the time taken by each transaction to a log file.
@@ -367,6 +379,7 @@ pgbench options dbname
-M querymode
+ --query-mode querymode
Protocol to use for submitting queries to the server:
@@ -389,6 +402,7 @@ pgbench options dbname
-n
+ --no-vacuum
Perform no vacuuming before running the test.
@@ -403,6 +417,7 @@ pgbench options dbname
-N
+ --skip-some-update
Do not update pgbench_tellers and
@@ -415,6 +430,7 @@ pgbench options dbname
-r
+ --report-latencies
Report the average per-statement latency (execution time from the
@@ -426,6 +442,7 @@ pgbench options dbname
-s scale_factor
+ --scale scale_factor
Report the specified scale factor in pgbench's
@@ -440,6 +457,7 @@ pgbench options dbname
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
W dniu 02.05.2013 19:40, Tom Lane pisze: >> BEFORE/AFTER seems more logical to me. > Works for me. > What do you think about function- or cast-like syntax. I mean: RETURNING OLD(foo.bar) or RETURNING OLD(foo).bar or RETURNING (foo::OLD).bar ? I think none of them should conflict with any other statements. Regards, Karol Trzcionka -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
David Fetter writes: > On Thu, May 02, 2013 at 06:28:53PM +0200, Andres Freund wrote: >> prior/after? Both are unreserved keywords atm and it seems far less >> likely to have conflicts than new/old. > BEFORE/AFTER seems more logical to me. Works for me. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
2013/5/2 Tom Lane > Marko Tiikkaja writes: > > What I'm more interested in is: how can we make this feature work in > > PL/PgSQL where OLD means something different? > > That's a really good point: if you follow this approach then you're > creating fundamental conflicts for use of the feature in trigger > functions or rules, which will necessarily have conflicting uses of > those names. Yeah, we could define scoping rules such that there's > an unambiguous interpretation, but then the user is just out of luck > if he wants to reference the other definition. (This problem is > probably actually worse if you implement with reserved words rather > than aliases.) > > I'm thinking it would be better to invent some other notation for access > to old-row values. > I am not sure, but I am thinking so NEW and OLD are used in some statements and features ANSI SQL 2012, so probably we should to do keywords from these words if we would to support modern ANSI SQL Regards Pavel > > regards, tom lane > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
Re: [HACKERS] high io BUT huge amount of free memory
> That's kind of my point. :) That 14GB isn't allocated to cache, buffers, > any process, or anything else. It's just... free. In the middle of the > day, where 800 PG threads are pulling 7000TPS on average. Based on that > scenario, I'd like to think it would cache pretty aggressively, but > instead, it's just leaving 14GB around to do absolutely nothing. > > It makes me sad. :( Yeah, this is why I want to go to Linux Plumbers this year. The Kernel.org engineers are increasingly doing things which makes Linux unsuitable for applications which depend on the filesystem. There is a good, but sad, reason for this: IBM and Oracle and their partners are the largest employers of people hacking on core Linux memory/IO functionality, and both of those companies use DirectIO extensively in their products. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
On Thu, May 02, 2013 at 06:28:53PM +0200, Andres Freund wrote: > On 2013-05-02 12:23:19 -0400, Tom Lane wrote: > > Marko Tiikkaja writes: > > > What I'm more interested in is: how can we make this feature work in > > > PL/PgSQL where OLD means something different? > > > > That's a really good point: if you follow this approach then you're > > creating fundamental conflicts for use of the feature in trigger > > functions or rules, which will necessarily have conflicting uses of > > those names. Yeah, we could define scoping rules such that there's > > an unambiguous interpretation, but then the user is just out of luck > > if he wants to reference the other definition. (This problem is > > probably actually worse if you implement with reserved words rather > > than aliases.) > > > > I'm thinking it would be better to invent some other notation for access > > to old-row values. > > prior/after? Both are unreserved keywords atm and it seems far less > likely to have conflicts than new/old. BEFORE/AFTER seems more logical to me. Yes, those words both have meaning in, for example, a trigger definition, but they're clearly separable by context. Yay, bike-shedding! Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Remaining beta blockers
On Tue, Apr 30, 2013 at 12:02:59PM -0400, Robert Haas wrote: > On Tue, Apr 30, 2013 at 10:40 AM, Kevin Grittner wrote: > >>> What is a real problem or risk with using this mechanism until we > >>> engineer something better? What problems with converting to a > >>> later major release does anyone see? > >> > >> Well, it's a pg_upgrade hazard, if nothing else, isn't it? > > > > I don't think so. What do you see as a problem? > > pg_upgrade only handles changes in catalog state, not on-disk > representation. If the on-disk representation of an non-scannable > view might change in a future release, it's a pg_upgrade hazard. Yes, pg_upgrade is never going to write to data pages as that would be slow and prevent the ability to roll back to the previous cluster on error. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
On 2013-05-02 12:23:19 -0400, Tom Lane wrote: > Marko Tiikkaja writes: > > What I'm more interested in is: how can we make this feature work in > > PL/PgSQL where OLD means something different? > > That's a really good point: if you follow this approach then you're > creating fundamental conflicts for use of the feature in trigger > functions or rules, which will necessarily have conflicting uses of > those names. Yeah, we could define scoping rules such that there's > an unambiguous interpretation, but then the user is just out of luck > if he wants to reference the other definition. (This problem is > probably actually worse if you implement with reserved words rather > than aliases.) > > I'm thinking it would be better to invent some other notation for access > to old-row values. prior/after? Both are unreserved keywords atm and it seems far less likely to have conflicts than new/old. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
Marko Tiikkaja writes: > What I'm more interested in is: how can we make this feature work in > PL/PgSQL where OLD means something different? That's a really good point: if you follow this approach then you're creating fundamental conflicts for use of the feature in trigger functions or rules, which will necessarily have conflicting uses of those names. Yeah, we could define scoping rules such that there's an unambiguous interpretation, but then the user is just out of luck if he wants to reference the other definition. (This problem is probably actually worse if you implement with reserved words rather than aliases.) I'm thinking it would be better to invent some other notation for access to old-row values. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
On 2013-05-02 17:32, Karol Trzcionka wrote: W dniu 02.05.2013 17:17, Tom Lane pisze: It should in any case be possible to do this without converting them to reserved words; rather the implementation could be that those table aliases are made available when parsing the UPDATE RETURNING expressions. (This is, in fact, the way that rules use these names now.) Probably it should work something like "add these aliases if they don't already exist in the query", so as to avoid breaking existing applications. I don't really see a lot of value in hacking the behavior of either INSERT RETURNING or DELETE RETURNING. what should happened in statement: UPDATE old SET foo=foo+1 RETURNING old.foo; If it returns old value, it'll break capability. If it returns new value (as now), there is no possibility to get old value (and user cries because of broken feature). In Tom's proposal that would give you the "new" value. Personally I would maybe prefer reserving NEW/OLD, but if we go through with Tom's idea, this should work: UPDATE old myold SET foo=foo+1 RETURNING myold.foo, old.foo; What I'm more interested in is: how can we make this feature work in PL/PgSQL where OLD means something different? Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
W dniu 02.05.2013 17:17, Tom Lane pisze: > It should in any case be possible to do this without converting them > to reserved words; rather the implementation could be that those table > aliases are made available when parsing the UPDATE RETURNING > expressions. (This is, in fact, the way that rules use these names > now.) Probably it should work something like "add these aliases if > they don't already exist in the query", so as to avoid breaking > existing applications. I don't really see a lot of value in hacking > the behavior of either INSERT RETURNING or DELETE RETURNING. regards, > tom lane I'm not sure about it. If it is not reserved keyword how can user get old value from table named "old". The new value is not a problem (doesn't conflict) but what should happened in statement: UPDATE old SET foo=foo+1 RETURNING old.foo; If it returns old value, it'll break capability. If it returns new value (as now), there is no possibility to get old value (and user cries because of broken feature). Regards, Karol Trzcionka -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
David Fetter writes: > 1. As the SQL standard mandates that OLD and NEW be reserved words, we'll > re-reserve them. As I mentioned yesterday, I'm not exactly thrilled with re-reserving those, and especially not NEW as it is utterly unnecessary (since the default would already be to return the NEW column). It should in any case be possible to do this without converting them to reserved words; rather the implementation could be that those table aliases are made available when parsing the UPDATE RETURNING expressions. (This is, in fact, the way that rules use these names now.) Probably it should work something like "add these aliases if they don't already exist in the query", so as to avoid breaking existing applications. I don't really see a lot of value in hacking the behavior of either INSERT RETURNING or DELETE RETURNING. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Confusing comment in xlog.c or am I missing something?
On 02.05.2013 18:05, Amit Langote wrote: Attached patch fixes this. ok, applied. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Confusing comment in xlog.c or am I missing something?
Attached patch fixes this. -- Amit Langote minor-xlog-comment-fix.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
On Thu, May 02, 2013 at 11:04:15AM +0200, Karol Trzcionka wrote: > Hello, > I'm student who want to participate in Google Summer of Code. I want to > implement feature which allows to get old values directly from update > statement. I mean there should be possibility to choose the value > immedietly before or after update in RETURNING statement. The syntax may > be realized as "aliases". That means: OLD keywordswould be alias to row > before update and NEW to row after update. The conclusion of syntax is: > UPDATE foo SET bar=bar+1 RETURNING OLD.bar AS old_bar, NEW.bar AS new_bar; > UPDATE foo SET ... RETURNING NEW.* will be equivalent to UPDATE foo SET > ... RETURNING foo.* > It may be possible to add similar syntax to DELETE and INSERT statements > but I'm not sure if it makes a sense (OLD for DELETE will be alias to > row before delete, NEW for INSERT will be alias to row after insert and > all triggers - however what about NEW for delete and OLD for INSERT?). > Additionally NEW and OLD values will be reserved keywords (it might be > some capability problem since in new PostgreSQL it isn't reserved - > however standard says it is and in old PgSQL it was). > I'd like to hear (read) yours feedback about syntax and/or implement > issues related to this proposal. > Regards, > Karol Trzcionka I would like to include the proposal as we've hammered it out together on IRC and on GSoC site below. Cheers, David. 1. As the SQL standard mandates that OLD and NEW be reserved words, we'll re-reserve them. 2. Let's make OLD and NEW have the same meaning that INSERT/UPDATE/DELETE have when returning rows from the changed table. In particular INSERT INTO foo (...) RETURNING NEW.* will be equivalent to INSERT INTO foo(...) RETURNING foo.* Similarly for UPDATE and DELETE: UPDATE foo SET ... RETURNING NEW.* will be equivalent to UPDATE foo SET ... RETURNING foo.* and DELETE FROM foo ... RETURNING OLD.* will be equivalent to DELETE FROM foo ... RETURNING foo.* As RETURNING clauses have access to everything in the FROM/USING clause, it is important to limit the NEW/OLD rows as being only those in the table being written to in the statement. 3. Let's add an option to UPDATE so that it can RETURN OLD with the same characteristics as above, namely that it refers only to constants and columns in the updated table and not to everything available from the USING clause if included. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_controldata gobbledygook
On Fri, Apr 26, 2013 at 08:51:23AM -0400, Robert Haas wrote: > On Fri, Apr 26, 2013 at 5:08 AM, Andres Freund wrote: > > I have to admit I don't see the point. None of those values is particularly > > interesting to anybody without implementation level knowledge and those > > will likely deal with them just fine. And I find the version with the > > shorter names far quicker to read. > > The clarity win here doesn't seem to be worth the price of potentially > > breaking some tools. > > +1. FYI, pg_upgrade would certainly have to be updated to handle this change. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Change to pg_test_fsync output
On Tue, Apr 16, 2013 at 07:10:38PM -0400, Bruce Momjian wrote: > I propose the attached patch to change pg_test_fsync's output from > "microsecs" to "usecs", which is the designation we use in other places. > Also remove parentheses, e.g. > > 1 * 16kB open_sync write8012.933 ops/sec 125 usecs/op > 2 * 8kB open_sync writes 5399.901 ops/sec 185 usecs/op > 4 * 4kB open_sync writes 3340.958 ops/sec 299 usecs/op > 8 * 2kB open_sync writes 1903.621 ops/sec 525 usecs/op > 16 * 1kB open_sync writes 1032.606 ops/sec 968 usecs/op > > This is new output for 9.3. Applied. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] \watch stuck on execution of commands returning no tuples
Michael Paquier writes: > Hi all, > When testing \watch, I noticed that process waits indefinitely when > executing it with a DDL or a DML. > For example: > postgres=# CREATE TABLE aa (a int); > postgres=# ANALYSE aa \watch 10 > -- Process waiting here It's not "waiting", it's doing the ANALYZE once every ten seconds, just like you told it to. Perhaps it'd be a good idea to emit the command tag on receiving a non-tuple-bearing result, just to make this more obvious. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] high io BUT huge amount of free memory
On 05/01/2013 06:37 PM, Bruce Momjian wrote: Sorry to be dense here, but what is the problem with that output? That there is a lot of memory marked as "free"? Why would it mark any memory free? That's kind of my point. :) That 14GB isn't allocated to cache, buffers, any process, or anything else. It's just... free. In the middle of the day, where 800 PG threads are pulling 7000TPS on average. Based on that scenario, I'd like to think it would cache pretty aggressively, but instead, it's just leaving 14GB around to do absolutely nothing. It makes me sad. :( -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604 312-676-8870 stho...@optionshouse.com __ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Cube extension improvement, GSoC
Hi Stas, and sorry for the late response. On 23.03.2013 01:10, Stas Kelvich wrote: * Adding point data type support to the cube extension in order to avoid storing of coincident upper left and lower right vertices, which may reduce the volume that leaf nodes occupy almost twice. Makes sense. I think it would be possible to implement this as an optimization to existing cube data type, so that a cube that is actually a point is simply stored more efficiently. Ie. set a flag in the NDBOX struct indicating that the cube is a point, and omit the second set of coordinates if that's set. * Learning cube extension to store dimensions with different data types. Such index would be good alternative to compound key B-Tree multi-index (suitable for diapason queries and data ordering). You mean, a cube containing something else than floats? I don't think we want to explode the number of datatypes by doing that, casting between them could be problematic. But I wonder if you could add cube-like operators for arrays. We already have support for arrays of any datatype, and any number of dimensions. That seems awfully lot like what the cube extension does. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [PATCH] pgbench --throttle (submission 4)
Minor changes wrt to the previous submission, so as to avoid running some
stuff twice under some conditions. This is for reference to the next
commit fest.
--
Fabien.diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c
index bc01f07..e692aa1 100644
--- a/contrib/pgbench/pgbench.c
+++ b/contrib/pgbench/pgbench.c
@@ -137,6 +137,12 @@ int unlogged_tables = 0;
double sample_rate = 0.0;
/*
+ * whether clients are throttled to a given rate, expressed as a delay in us.
+ * 0, the default means no throttling.
+ */
+int64 throttle = 0;
+
+/*
* tablespace selection
*/
char *tablespace = NULL;
@@ -204,6 +210,8 @@ typedef struct
int nvariables;
instr_time txn_begin; /* used for measuring transaction latencies */
instr_time stmt_begin; /* used for measuring statement latencies */
+ int64 trigger; /* previous/next throttling (us) */
+ bool throttled; /* whether current transaction was throttled */
int use_file; /* index in sql_files for this client */
bool prepared[MAX_FILES];
} CState;
@@ -361,6 +369,9 @@ usage(void)
" -S perform SELECT-only transactions\n"
" -t NUM number of transactions each client runs (default: 10)\n"
" -T NUM duration of benchmark test in seconds\n"
+ " -H SPEC, --throttle SPEC\n"
+ " delay in second to throttle each client\n"
+ " sample specs: 0.025 40tps 25ms 25000us\n"
" -v vacuum all four standard tables before tests\n"
"\nCommon options:\n"
" -d print debugging output\n"
@@ -1027,7 +1038,7 @@ top:
}
}
- if (commands[st->state]->type == SQL_COMMAND)
+ if (!st->throttled && commands[st->state]->type == SQL_COMMAND)
{
/*
* Read and discard the query result; note this is not included in
@@ -1049,26 +1060,54 @@ top:
discard_response(st);
}
- if (commands[st->state + 1] == NULL)
+ /* some stuff done at the end, once */
+ if (commands[st->state + 1] == NULL && !st->throttled)
{
+ /* disconnect if required */
if (is_connect)
{
PQfinish(st->con);
st->con = NULL;
}
+ /* update transaction counter and possibly end */
++st->cnt;
if ((st->cnt >= nxacts && duration <= 0) || timer_exceeded)
return clientDone(st, true); /* exit success */
+
+ /* handle throttling once, as the last post-transaction stuff */
+ if (throttle)
+ {
+/* compute delay to approximate a Poisson distribution
+ * 100 => 13.8 .. 0 multiplier
+ * if transactions are too slow or a given wait shorter than
+ * a transaction, the next transaction will start right away.
+ */
+int64 wait = (int64)
+ throttle * -log(getrand(thread, 1, 100)/100.0);
+st->trigger += wait;
+st->sleeping = 1;
+st->until = st->trigger;
+st->throttled = true;
+if (debug)
+ fprintf(stderr, "client %d throttling "INT64_FORMAT" us\n",
+ st->id, wait);
+/* throttling inserted a sleep which is handled first
+ * before proceeding next to resetting the state
+ */
+return true;
+ }
}
- /* increment state counter */
+ /* increment state counter, possibly after throttling */
st->state++;
if (commands[st->state] == NULL)
{
+ /* reset */
st->state = 0;
st->use_file = (int) getrand(thread, 0, num_files - 1);
commands = sql_files[st->use_file];
+ st->throttled = false;
}
}
@@ -2086,6 +2125,7 @@ main(int argc, char **argv)
{"unlogged-tables", no_argument, &unlogged_tables, 1},
{"sampling-rate", required_argument, NULL, 4},
{"aggregate-interval", required_argument, NULL, 5},
+ {"throttle", required_argument, NULL, 'H'},
{NULL, 0, NULL, 0}
};
@@ -2152,7 +2192,7 @@ main(int argc, char **argv)
state = (CState *) pg_malloc(sizeof(CState));
memset(state, 0, sizeof(CState));
- while ((c = getopt_long(argc, argv, "ih:nvp:dqSNc:j:Crs:t:T:U:lf:D:F:M:", long_options, &optindex)) != -1)
+ while ((c = getopt_long(argc, argv, "ih:nvp:dqSNc:j:Crs:t:T:U:lf:D:F:M:H:", long_options, &optindex)) != -1)
{
switch (c)
{
@@ -2307,6 +2347,26 @@ main(int argc, char **argv)
exit(1);
}
break;
+ case 'H':
+ {
+/* get a double from the beginning of option value */
+double throttle_value = atof(optarg);
+if (throttle_value <= 0.0)
+{
+ fprintf(stderr, "invalid throttle value: %s\n", optarg);
+ exit(1);
+}
+/* rough handling of possible units */
+if (strstr(optarg, "us"))
+ throttle = (int64) throttle_value;
+else if (strstr(optarg, "ms"))
+ throttle = (int64) (1000.0 * throttle_value);
+else if (strstr(optarg, "tps"))
+ throttle = (int64) (100.0 / throttle_value);
+else /* assume that default is in second */
+ throttle = (int64) (100.0 * throttle_value);
+ }
+break;
case 0:
/* This covers long options which take no argument. */
break;
@@ -2533,6 +2593,18 @@ main(int argc, char **arg
[HACKERS] [PATCH] add --progress option to pgbench
Please find attached a small patch submission, for reference to the next
commit fest.
Each thread reports its progress about every the number of seconds
specified with the option. May be particularly useful for long running
pgbench invocations, which should always be the case.
shell> ./pgbench -T 16 --progress 5 -c 4 -j 2 test
starting vacuum...end.
thread 0 running at 53.194457 tps after 5.0 s
thread 1 running at 59.792203 tps after 5.0 s
[ b... ]
thread 0 running at 56.050592 tps after 10.0 s
thread 1 running at 54.075444 tps after 10.1 s
[ b... ]
thread 0 running at 49.746026 tps after 15.0 s
thread 1 running at 48.560258 tps after 15.1 s
[ b... ]
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 4
number of threads: 2
duration: 16 s
number of transactions actually processed: 1725
tps = 107.034958 (including connections establishing)
tps = 107.094691 (excluding connections establishing)
--
Fabien.diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c
index bc01f07..f5de7ab 100644
--- a/contrib/pgbench/pgbench.c
+++ b/contrib/pgbench/pgbench.c
@@ -163,6 +163,7 @@ char *index_tablespace = NULL;
bool use_log; /* log transaction latencies to a file */
bool use_quiet; /* quiet logging onto stderr */
int agg_interval; /* log aggregates instead of individual transactions */
+int progress = 0; /* thread progress report every this seconds */
bool is_connect; /* establish connection for each transaction */
bool is_latencies; /* report per-command latencies */
int main_pid; /* main process id used in log filename */
@@ -361,6 +362,8 @@ usage(void)
" -S perform SELECT-only transactions\n"
" -t NUM number of transactions each client runs (default: 10)\n"
" -T NUM duration of benchmark test in seconds\n"
+ " -P SEC, --progress SEC\n"
+ " show thread progress report every SEC seconds\n"
" -v vacuum all four standard tables before tests\n"
"\nCommon options:\n"
" -d print debugging output\n"
@@ -2086,6 +2089,7 @@ main(int argc, char **argv)
{"unlogged-tables", no_argument, &unlogged_tables, 1},
{"sampling-rate", required_argument, NULL, 4},
{"aggregate-interval", required_argument, NULL, 5},
+ {"progress", required_argument, NULL, 'P'},
{NULL, 0, NULL, 0}
};
@@ -2152,7 +2156,7 @@ main(int argc, char **argv)
state = (CState *) pg_malloc(sizeof(CState));
memset(state, 0, sizeof(CState));
- while ((c = getopt_long(argc, argv, "ih:nvp:dqSNc:j:Crs:t:T:U:lf:D:F:M:", long_options, &optindex)) != -1)
+ while ((c = getopt_long(argc, argv, "ih:nvp:dqSNc:j:Crs:t:T:U:lf:D:F:M:P:", long_options, &optindex)) != -1)
{
switch (c)
{
@@ -2307,6 +2311,16 @@ main(int argc, char **argv)
exit(1);
}
break;
+ case 'P':
+progress = atoi(optarg);
+if (progress <= 0)
+{
+ fprintf(stderr,
+ "thread progress delay (-P) must not be negative (%s)\n",
+ optarg);
+ exit(1);
+}
+break;
case 0:
/* This covers long options which take no argument. */
break;
@@ -2666,6 +2680,9 @@ threadRun(void *arg)
int nstate = thread->nstate;
int remains = nstate; /* number of remaining clients */
int i;
+ /* for reporting progress: */
+ int64 last_report = INSTR_TIME_GET_MICROSEC(thread->start_time);
+ int64 last_count = 0;
AggVals aggs;
@@ -2829,6 +2846,29 @@ threadRun(void *arg)
st->con = NULL;
}
}
+
+ /* per thread progress report, about every 5s */
+ if (progress)
+ {
+ instr_time now_time;
+ int64 now, run;
+ INSTR_TIME_SET_CURRENT(now_time);
+ now = INSTR_TIME_GET_MICROSEC(now_time);
+ run = now - last_report;
+ if (run >= progress * 100)
+ {
+/* generate and show report */
+int64 count = 0;
+for (i=0; itid, 100.0 * (count-last_count) / run,
+ (now - INSTR_TIME_GET_MICROSEC(thread->start_time))/
+ 100.0);
+last_count = count;
+last_report = now;
+ }
+ }
}
done:
diff --git a/doc/src/sgml/pgbench.sgml b/doc/src/sgml/pgbench.sgml
index 79b4baf..01c2f7c 100644
--- a/doc/src/sgml/pgbench.sgml
+++ b/doc/src/sgml/pgbench.sgml
@@ -425,6 +425,16 @@ pgbench options dbname
+ -P sec
+ --progress sec
+
+
+ Show thread progress report about every sec seconds.
+
+
+
+
+
-s scale_factor
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] GSOC13 proposal - extend RETURNING syntax
Hello, I'm student who want to participate in Google Summer of Code. I want to implement feature which allows to get old values directly from update statement. I mean there should be possibility to choose the value immedietly before or after update in RETURNING statement. The syntax may be realized as "aliases". That means: OLD keywordswould be alias to row before update and NEW to row after update. The conclusion of syntax is: UPDATE foo SET bar=bar+1 RETURNING OLD.bar AS old_bar, NEW.bar AS new_bar; UPDATE foo SET ... RETURNING NEW.* will be equivalent to UPDATE foo SET ... RETURNING foo.* It may be possible to add similar syntax to DELETE and INSERT statements but I'm not sure if it makes a sense (OLD for DELETE will be alias to row before delete, NEW for INSERT will be alias to row after insert and all triggers - however what about NEW for delete and OLD for INSERT?). Additionally NEW and OLD values will be reserved keywords (it might be some capability problem since in new PostgreSQL it isn't reserved - however standard says it is and in old PgSQL it was). I'd like to hear (read) yours feedback about syntax and/or implement issues related to this proposal. Regards, Karol Trzcionka -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] add --throttle to pgbench (submission 3)
Hello Greg, If you add this to https://commitfest.postgresql.org/action/commitfest_view?id=18 I'll review it next month. Ok. Thanks. I just did that. I have a lot of use cases for a pgbench that doesn't just run at 100% all the time. I had tried to simulate something with simple sleep calls, but I realized it was going to take a stronger math basis to do the job well. The situations where I expect this to be useful all require collecting latency data and then both plotting it and doing some statistical analysis. pgbench-tools computes worst-case and 90th percentile latency for example, along with the graph over time. There's a useful concept that some of the official TPC tests have: how high can you get the throughput while still keeping the latency within certain parameters. Right now we have no way to simulate that. What we see with write-heavy pgbench is that latency goes crazy (>60 second commits sometimes) if all you do is hit the server with maximum throughput. That's interesting, but it's not necessarily relevant in many cases. Indeed. It is a good thing that my proposed feature can help in more situations than my particular need. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Recovery target 'immediate'
On 2 May 2013 08:31, Magnus Hagander wrote: > That said, there is one property that's very unclear now and that's > that you can only set one of recovery_target_time, recovery_target_xid > and recovery_target_name. But they can be freely combined with > recovery_target_timeline and recovery_target_inclusive. That's quite > confusing. In the docs we say "At most one of recovery_target_time, recovery_target_name or recovery_target_xid can be specified." on each of those parameter descriptions. In recovery.conf.sample, we say # You may set a recovery target either by transactionId, by name, # or by timestamp. Recovery may either include or exclude the # transaction(s) with the recovery target value (ie, stop either # just after or just before the given target, respectively). Who is confused by that? And if they are, why would they be less confused with changed *syntax*? I think most people just copy the examples anyway, they don't care about the syntax. As we just saw, changing the syntax may introduce other consistency issues and confusions that weren't there before. If the precise syntax is the essence of a new and improved interface, surely it needs to be fully worked out before anybody agrees. It has always been the case that recovery is a complex topic and one that is used in stressful circumstances. It isn't the syntax that makes using this hard, its the fact that the process itself is non-trivial and not easy to use without some prior thought and testing of how recovery will work for a particular company/enterprise. I'm very progressive about both new features and usability improvements, but rearranging things for minor reasons just feels like a waste. If we feel strongly about user interface design problems we should treat them the same way we treat performance issues. Profile to identify problem areas, analyze problems in those areas and suggest solutions, then make tests to check that the new interface genuinely works better than the old. That is proper UI improvement, not just knee jerk reactions. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Documentation epub format
On 05/01/2013 11:36 PM, Gavin Flower wrote: On 02/05/13 15:23, Peter Eisentraut wrote: On Wed, 2013-05-01 at 18:27 +0200, Fabien COELHO wrote: I must admit that there is a bit of a disappointement as far as the user experience is concerned: the generated file is barely usable on an iPad2 with the default iBooks reader, which was clearly not designed for handling a "4592" pages book (from its point of view). Well, clearly there are mainstream books that have 1000 pages, so it ought to be designed for that. It's not clear to me then why it necessarily must fail at 4000 pages. I think you might want to run some experiments to see what the reader can handle before we start doing anything. There might be something silly in some eReaders, like reserving 12 bits for page numbers internally - as 'no one will ever want a book with more than 4095 pages!'? My ancient Sony PRS-505 e-reader has the epub paginated at 5200 pages, and it seems to work just fine, if a bit slowly. It's possibly worth noting that the epub is about 1.5 times the size of that for War and Peace. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Recovery target 'immediate'
On Thu, May 2, 2013 at 8:55 AM, Simon Riggs wrote: > On 26 April 2013 18:13, Heikki Linnakangas wrote: >> On 26.04.2013 19:50, Magnus Hagander wrote: >>> >>> On Fri, Apr 26, 2013 at 6:43 PM, Simon Riggs >>> wrote: On 26 April 2013 17:25, Heikki Linnakangas wrote: > > Actually, from a usability point of view I think would be nice to have > just > > one setting, "recovery_target". It's already somewhat confusing to have > recovery_target_xid, recovery_target_time, and recovery_target_name, > which > are mutually exclusive, and recovery_target_inclusive which is just a > modifier for the others. Maybe something like: > > recovery_target = 'xid 1234' > recovery_target = 'xid 1234 exclusive' > recovery_target = '2013-04-22 12:33' > recovery_target = '2013-04-22 12:33 exclusive' > recovery_target = 'consistent' > recovery_target = 'name: daily backup' So now you want to change the whole existing API so it fits with your one new requirement? >> >> >> No, I think the above would be a usability improvement whether or not we add >> the new feature. > > > I don't see the usability improvement. This is only being suggested to > make one new addition look cleaner; there isn't a common gripe that > the use of parameters is hard to use, other than their location and > the ability to treat them as GUCs. Actually, there is - I hear it quite often from people not so experienced in PostgreSQL. Though in fairness, I'm not entirely sure the new syntax would help - some of those need a tool to do it for them, really (and such tools exist, I believe). That said, there is one property that's very unclear now and that's that you can only set one of recovery_target_time, recovery_target_xid and recovery_target_name. But they can be freely combined with recovery_target_timeline and recovery_target_inclusive. That's quite confusing. > This changes the existing API which will confuse people that know it > and invalidate everything written in software and on wikis as to how > to do it. That means all the "in case of fire break glass" > instructions are all wrong and need to be rewritten and retested. Yes, *that* is the main reason *not* to make the change. It has a pretty bad cost in backwards compatibility loss. There is a gain, but I don't think it outweighs the cost. > It also introduces a single common datatype for such entries, where > before we had that xids were numbers, names were text, so this new > mechanism operates completely differently from all other GUC > parameters. > > Plus its inconsistent, in that with xids you have 'xid 1234' whereas > timestamps just say '2013-04-22' rather than 'timestamp 2013-04-22', > or with names should they end in a colon or not. There'n no clear > differentiation between text for names and other keywords. Presumably > we'll need a complex parser to sort that out. I'm assuming that was just typos in Heikki's example. I'm sure he meant them to be consistent. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
