Re: [HACKERS] renaming contrib. (was multi-platform, multi-locale regression tests)
On 11/10/2010 07:51 PM, Robert Haas wrote: (And no, don't you dare breathe a word about git making that all automagically better. I have enough back-patching experience with git by now to be unimpressed; in fact, I notice that its rename-tracking feature falls over entirely when trying to back-patch further than 8.3. Apparently there's some hardwired limit on the number of files it can cope with.) That's very sad. Did you file a bug? It's intentional behavior. It gives up when there are too many differences to avoid being slow. We should adopt that philosophy. I suggest we limit all tables in future to 1m rows in the interests of speed. 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] renaming contrib. (was multi-platform, multi-locale regression tests)
On Thu, Nov 11, 2010 at 8:28 AM, Andrew Dunstan and...@dunslane.net wrote: It's intentional behavior. It gives up when there are too many differences to avoid being slow. And, it's configurable, at least to diff and merge. If it's not available in all the other porcelains, yes, that would be bugs that should be fixed: -lnum The -M and -C options require O(n^2) processing time where n is the number of potential rename/copy targets. This option prevents rename/copy detection from running if the number of rename/copy targets exceeds the specified number. And can even be specified as config options diff.renameLimit and merge.renameLimit. We should adopt that philosophy. I suggest we limit all tables in future to 1m rows in the interests of speed. As long as it's configurable, and if it would make operations on smaller tables faster, than go for it. And we should by defualt limit shared_buffers to 32MB. Oh wait. There are always tradeoffs when picking defaults, a-la-postgresql.conf. We as a community are generally pretty quick to pick up the defaults are very conservative, make sure you tune ... song when people complain about pg being too slow ;-) a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- 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] renaming contrib. (was multi-platform, multi-locale regression tests)
Aidan Van Dyk ai...@highrise.ca writes: It's intentional behavior. It gives up when there are too many differences to avoid being slow. And, it's configurable, at least to diff and merge. If it's not available in all the other porcelains, yes, that would be bugs that should be fixed: FWIW, I was seeing this with git cherry-pick, whose man page gives no hint of supporting any such option. -lnum The -M and -C options require O(n^2) processing time where n is the number of potential rename/copy targets. This option prevents rename/copy detection from running if the number of rename/copy targets exceeds the specified number. Given that we have, in fact, never renamed any files in the history of the project, I'm wondering exactly why it thinks that the number of potential rename/copy targets isn't zero. The whole thing smells broken to me, which is why I am unhappy about the idea of suddenly starting to depend on it in a big way. 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] renaming contrib. (was multi-platform, multi-locale regression tests)
On Thu, Nov 11, 2010 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote: Given that we have, in fact, never renamed any files in the history of the project, I'm wondering exactly why it thinks that the number of potential rename/copy targets isn't zero. The whole thing smells broken to me, which is why I am unhappy about the idea of suddenly starting to depend on it in a big way. Because git doesn't do rename tracking at all -- a rename operation is no different from a delete+add operation. Instead it tracks how lines of code move around in the tree: https://git.wiki.kernel.org/index.php/GitFaq#Why_does_git_not_.22track.22_renames.3F Regards, Marti -- 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] renaming contrib. (was multi-platform, multi-locale regression tests)
Aidan Van Dyk ai...@highrise.ca writes: Can you share what commit you were trying to cherry-pick, and what your resulting commit was? I can try and take a quick look at them and see if there is something obviously fishy with how git's trying to merge the new commit on the old tree... See yesterday's line_construct_pm() patches. I committed in HEAD and then did git cherry-pick master in each back branch. These all worked, which would be the minimum expectation for a single-file patch against a function that hasn't changed since 1999. But in the older branches it bleated about shutting off rename detection because of too many files (sorry, don't have the exact message in front of me, but that was the gist of it). Not the sort of thing that gives one a warm feeling about the tool. I've seen this before when trying to use git cherry-pick, but I forget on which other patches exactly. Oh, for the record: $ git --version git version 1.7.3 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] renaming contrib. (was multi-platform, multi-locale regression tests)
Marti Raudsepp ma...@juffo.org writes: On Thu, Nov 11, 2010 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote: Given that we have, in fact, never renamed any files in the history of the project, I'm wondering exactly why it thinks that the number of potential rename/copy targets isn't zero. Because git doesn't do rename tracking at all -- a rename operation is no different from a delete+add operation. Instead it tracks how lines of code move around in the tree: https://git.wiki.kernel.org/index.php/GitFaq#Why_does_git_not_.22track.22_renames.3F Hmmm ... so rename tracking is O(N^2) in the total number of patches applied, or lines patched, or some such measure, between the branches you're trying to patch between? Ugh. Doesn't sound like something we want to grow dependent on. 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] renaming contrib. (was multi-platform, multi-locale regression tests)
On 11/11/2010 10:17 AM, Aidan Van Dyk wrote: We should adopt that philosophy. I suggest we limit all tables in future to 1m rows in the interests of speed. As long as it's configurable, and if it would make operations on smaller tables faster, than go for it. And we should by defualt limit shared_buffers to 32MB. Oh wait. There are always tradeoffs when picking defaults, a-la-postgresql.conf. We as a community are generally pretty quick to pick up the defaults are very conservative, make sure you tune ... song when people complain about pg being too slow ;-) Well, I was of course being facetious. But since you mention it, Postgres is conservative about its defaults because it's a server. I don't think quite the same considerations apply to developer software that will be running on a workstation. And Tom's complaint was about what he saw as incorrect behavior. Our defaults might hurt performance, but I don't think they trade speed for incorrect behavior. Anyway, revenons à nos moutons. 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] renaming contrib. (was multi-platform, multi-locale regression tests)
On Thu, Nov 11, 2010 at 6:08 PM, Tom Lane t...@sss.pgh.pa.us wrote: Marti Raudsepp ma...@juffo.org writes: On Thu, Nov 11, 2010 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote: Given that we have, in fact, never renamed any files in the history of the project, I'm wondering exactly why it thinks that the number of potential rename/copy targets isn't zero. Because git doesn't do rename tracking at all -- a rename operation is no different from a delete+add operation. Instead it tracks how lines of code move around in the tree: https://git.wiki.kernel.org/index.php/GitFaq#Why_does_git_not_.22track.22_renames.3F Hmmm ... so rename tracking is O(N^2) in the total number of patches applied, or lines patched, or some such measure, between the branches you're trying to patch between? Ugh. Doesn't sound like something we want to grow dependent on. No, it's dependant on files changed between two trees. It does not analyze history when doing rename tracking. Default limit is 200. It should be easy to calculate whats needed for Postgres. -- marko -- 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] renaming contrib. (was multi-platform, multi-locale regression tests)
On 11/10/2010 06:17 PM, Tom Lane wrote: David E. Wheelerda...@kineticode.com writes: On Nov 10, 2010, at 2:15 PM, Andrew Dunstan wrote: We already use some contrib stuff in the regression tests. (It really is time we stopped calling it contrib.) Call them core extensions. Works well considering Dimitri's work, which explicitly makes them extensions. So maybe change the directory name to extensions or ext? We've been calling it contrib for a dozen years, so that name is pretty well baked in by now. IMO renaming it is pointless and will accomplish little beyond creating confusion and making back-patches harder. The current name causes constant confusion. It's a significant misnomer, and leads people to distrust the code. There might be reasons not to change, but you should at least recognize why the suggestion is being made. (And no, don't you dare breathe a word about git making that all automagically better. I have enough back-patching experience with git by now to be unimpressed; in fact, I notice that its rename-tracking feature falls over entirely when trying to back-patch further than 8.3. Apparently there's some hardwired limit on the number of files it can cope with.) That's very sad. Did you file a bug? 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] renaming contrib. (was multi-platform, multi-locale regression tests)
On Wed, Nov 10, 2010 at 8:05 PM, Andrew Dunstan and...@dunslane.net wrote: On 11/10/2010 07:51 PM, Robert Haas wrote: On Wed, Nov 10, 2010 at 7:01 PM, Andrew Dunstanand...@dunslane.net wrote: The current name causes constant confusion. It's a significant misnomer, and leads people to distrust the code. There might be reasons not to change, but you should at least recognize why the suggestion is being made. Is it your position that contrib code is as well-vetted as core code? A damn sight more than it used to be. I claim a bit of credit for that - before the buildfarm existed it was quite poorly tested, but we can't get away with that any more. (Ditto PLs and ECPG once we added those into the buildfarm mix.) Of course, there are odd corners in the code. But hstore, for example, has just had a major makeover, and pgcrypto is pretty well maintained. Some other modules are less well loved. There are a few small bits of the core code that have cobwebs too. Fair enough. I think overall our code quality is good, and, over time, it's probably risen both within and outside core. Still, I think renaming contrib would likely be a lot more hassle than it's worth, and I don't think it would do much to remove the central issue, which is that installing extensions is a pain in the neck. Dimitri's work will help with that somewhat, but there's still that nasty business of needing to update shared_preload_libraries and bounce the server, at least for some modules. -- Robert Haas 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] renaming contrib. (was multi-platform, multi-locale regression tests)
On 11/10/2010 07:51 PM, Robert Haas wrote: On Wed, Nov 10, 2010 at 7:01 PM, Andrew Dunstanand...@dunslane.net wrote: The current name causes constant confusion. It's a significant misnomer, and leads people to distrust the code. There might be reasons not to change, but you should at least recognize why the suggestion is being made. Is it your position that contrib code is as well-vetted as core code? A damn sight more than it used to be. I claim a bit of credit for that - before the buildfarm existed it was quite poorly tested, but we can't get away with that any more. (Ditto PLs and ECPG once we added those into the buildfarm mix.) Of course, there are odd corners in the code. But hstore, for example, has just had a major makeover, and pgcrypto is pretty well maintained. Some other modules are less well loved. There are a few small bits of the core code that have cobwebs too. 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] renaming contrib. (was multi-platform, multi-locale regression tests)
On Wed, Nov 10, 2010 at 7:01 PM, Andrew Dunstan and...@dunslane.net wrote: The current name causes constant confusion. It's a significant misnomer, and leads people to distrust the code. There might be reasons not to change, but you should at least recognize why the suggestion is being made. Is it your position that contrib code is as well-vetted as core code? (And no, don't you dare breathe a word about git making that all automagically better. I have enough back-patching experience with git by now to be unimpressed; in fact, I notice that its rename-tracking feature falls over entirely when trying to back-patch further than 8.3. Apparently there's some hardwired limit on the number of files it can cope with.) That's very sad. Did you file a bug? It's intentional behavior. It gives up when there are too many differences to avoid being slow. -- Robert Haas 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
