Обсуждение: Re: [PERFORM] No hash join across partitioned tables?
(moving to -hackers) On Wed, Jun 9, 2010 at 4:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> In going back through emails I had marked as possibly needing another >> look before 9.0 is released, I came across this issue again. As I >> understand it, analyze (or analyse) now collects statistics for both >> the parent individually, and for the parent and its children together. >> However, as I further understand it, autovacuum won't actually fire >> off an analyze unless there's enough activity on the parent table >> considered individually to warrant it. So if you have an empty parent >> and a bunch of children with data in it, your stats will still stink, >> unless you analyze by hand. > > Check. > >> Assuming my understanding of the problem is correct, we could: > >> (a) fix it, >> (b) document that you should consider periodic manual analyze commands >> in this situation, or >> (c) do nothing. > >> Thoughts? > > The objections to (a) are that it might result in excessive ANALYZE work > if not done intelligently, and that we haven't got a patch ready anyway. > I would have liked to get to this for 9.0 but I feel it's a bit late > now. I guess I can't really disagree with that. Should we try to document this in some way? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Greetings all, I have been trying to create/run a build farm as part of a project I am working on. However, I have noticed the primary git repostitory, git.postgresql.org/git, does not seem to be working. Namely, whenever I try to clone the directory, I receive this error: Error: Unable to find 5e4933c31d3cd2750ee1793efe6eca43055fb273e under http://git.postgresql.org/git/postgresql.git Cannot obtain needed blob 5e4933c31d3cd2750ee1793efe6eca4305fb273e while processing commit c5609c66ce2ee4fdb180be95721252b47f90499 Error: fetch failed. I thought it would be prudent to notify the list so someone could possibly check into this. Thanks! Scott Luxenberg
Luxenberg, Scott I. wrote: > Greetings all, > > I have been trying to create/run a build farm as part of a project I am > working on. That seems an odd thing to do since we have one ... > However, I have noticed the primary git repostitory, > git.postgresql.org/git, does not seem to be working. Namely, whenever I > try to clone the directory, I receive this error: > > Error: Unable to find 5e4933c31d3cd2750ee1793efe6eca43055fb273e under > http://git.postgresql.org/git/postgresql.git > Cannot obtain needed blob 5e4933c31d3cd2750ee1793efe6eca4305fb273e while > processing commit c5609c66ce2ee4fdb180be95721252b47f90499 > Error: fetch failed. > > I thought it would be prudent to notify the list so someone could > possibly check into this. > > > Why are you cloning over http? Here is the best way to clone, which seems to be working: [andrew@sophia ]$ git clone --mirror git://git.postgresql.org/git/postgresql.git Initialized empty Git repositoryin /home/andrew/postgresql.git/ remote: Counting objects: 376865, done. remote: Compressing objects: 100% (87569/87569),done. remote: Total 376865 (delta 310187), reused 352950 (delta 287485) Receiving objects: 100% (376865/376865),178.73 MiB | 251 KiB/s, done. Resolving deltas: 100% (310187/310187), done. [andrew@sophia ]$ cheers andrew
Stephen Frost wrote: > * Andrew Dunstan (andrew@dunslane.net) wrote: > >> Luxenberg, Scott I. wrote: >> >>> I have been trying to create/run a build farm as part of a project I am >>> working on. >>> >> That seems an odd thing to do since we have one ... >> > > To clarify, he's setting up a build farm *member*. :) > Aha. Amazing the difference one little word can make ... > > As a side-note, it works just fine from git-hub's http mirror and that's > what we've been playing with, but I don't know if we want to recommend > that for build-farm members.. > > > I don't see why not. Buildfarm members are going to have to reset their repos when we finally cut over in a few months. Luckily, this is a fairly painless operation - blow away the repo and change the config file and the script will resync as if nothing had happened. cheers andrew
* Andrew Dunstan (andrew@dunslane.net) wrote: > I don't see why not. Buildfarm members are going to have to reset their > repos when we finally cut over in a few months. Luckily, this is a > fairly painless operation - blow away the repo and change the config > file and the script will resync as if nothing had happened. Should we stop bothering to offer http://git.postgresql.org then..? Or do we expect it to get fixed and work correctly once we cut over and rebuild? Also, perhaps we could list the git-hub option on the wiki (http://wiki.postgresql.org/wiki/Other_Git_Repositories)? (and, yea, it's the same me) Thanks, Stephen
On Thu, Jun 10, 2010 at 18:20, Stephen Frost <sfrost@snowman.net> wrote: > * Andrew Dunstan (andrew@dunslane.net) wrote: >> I don't see why not. Buildfarm members are going to have to reset their >> repos when we finally cut over in a few months. Luckily, this is a >> fairly painless operation - blow away the repo and change the config >> file and the script will resync as if nothing had happened. > > Should we stop bothering to offer http://git.postgresql.org then..? Or No, we should not. Especially if someone has a clue how to do it. The last time I fixed it by runnin repack, but that didn't work this time. I have no clue why it's asking for a file that doesn't exist. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Excerpts from Andrew Dunstan's message of jue jun 10 11:26:59 -0400 2010: > Why are you cloning over http? Here is the best way to clone, which > seems to be working: > > [andrew@sophia ]$ git clone --mirror > git://git.postgresql.org/git/postgresql.git > Initialized empty Git repository in /home/andrew/postgresql.git/ In case you're a git-ignorant like me and are wondering why the above does not produce a usable checkout, the complete recipe is here: http://archives.postgresql.org/message-id/20090602162347.GF23972@yugib.highrise.ca (in short, you need a git clone --reference) -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
> Why are you cloning over http? Me too I've used http, since I'm behind a proxy and I couldn't find a "simple" way of having the git:// method working behind a proxy...
* Andrew Dunstan (andrew@dunslane.net) wrote: > Luxenberg, Scott I. wrote: > >I have been trying to create/run a build farm as part of a project I am > >working on. > > That seems an odd thing to do since we have one ... To clarify, he's setting up a build farm *member*. :) > >However, I have noticed the primary git repostitory, > >git.postgresql.org/git, does not seem to be working. Namely, whenever I > >try to clone the directory, I receive this error: > > > >Error: Unable to find 5e4933c31d3cd2750ee1793efe6eca43055fb273e under > >http://git.postgresql.org/git/postgresql.git > >Cannot obtain needed blob 5e4933c31d3cd2750ee1793efe6eca4305fb273e while > >processing commit c5609c66ce2ee4fdb180be95721252b47f90499 > >Error: fetch failed. > > > >I thought it would be prudent to notify the list so someone could > >possibly check into this. > > > Why are you cloning over http? Here is the best way to clone, which > seems to be working: Unfortunately for us, the port that git uses isn't currently allowed outbound by our corporate firewall. I expect that to be true for other PG users who want git and for some build-farm members, so I think we really need to support git cloning over http. As a side-note, it works just fine from git-hub's http mirror and that's what we've been playing with, but I don't know if we want to recommend that for build-farm members.. Thanks! Stephen
On Thursday 10 June 2010 19:30:00 Magnus Hagander wrote: > On Thu, Jun 10, 2010 at 18:20, Stephen Frost <sfrost@snowman.net> wrote: > > * Andrew Dunstan (andrew@dunslane.net) wrote: > >> I don't see why not. Buildfarm members are going to have to reset their > >> repos when we finally cut over in a few months. Luckily, this is a > >> fairly painless operation - blow away the repo and change the config > >> file and the script will resync as if nothing had happened. > > > > Should we stop bothering to offer http://git.postgresql.org then..? Or > > No, we should not. > > Especially if someone has a clue how to do it. The last time I fixed > it by runnin repack, but that didn't work this time. I have no clue > why it's asking for a file that doesn't exist. Does the repo run 'update-server-info' in some hook? Andres
On Fri, Jun 11, 2010 at 19:12, Andres Freund <andres@anarazel.de> wrote: > On Thursday 10 June 2010 19:30:00 Magnus Hagander wrote: >> On Thu, Jun 10, 2010 at 18:20, Stephen Frost <sfrost@snowman.net> wrote: >> > * Andrew Dunstan (andrew@dunslane.net) wrote: >> >> I don't see why not. Buildfarm members are going to have to reset their >> >> repos when we finally cut over in a few months. Luckily, this is a >> >> fairly painless operation - blow away the repo and change the config >> >> file and the script will resync as if nothing had happened. >> > >> > Should we stop bothering to offer http://git.postgresql.org then..? Or >> >> No, we should not. >> >> Especially if someone has a clue how to do it. The last time I fixed >> it by runnin repack, but that didn't work this time. I have no clue >> why it's asking for a file that doesn't exist. > Does the repo run 'update-server-info' in some hook? Yup, it runs after every time it pulls from cvs. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Thu, Jun 10, 2010 at 9:29 AM, Robert Haas <robertmhaas@gmail.com> wrote: > (moving to -hackers) > > On Wed, Jun 9, 2010 at 4:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> In going back through emails I had marked as possibly needing another >>> look before 9.0 is released, I came across this issue again. As I >>> understand it, analyze (or analyse) now collects statistics for both >>> the parent individually, and for the parent and its children together. >>> However, as I further understand it, autovacuum won't actually fire >>> off an analyze unless there's enough activity on the parent table >>> considered individually to warrant it. So if you have an empty parent >>> and a bunch of children with data in it, your stats will still stink, >>> unless you analyze by hand. >> >> Check. >> >>> Assuming my understanding of the problem is correct, we could: >> >>> (a) fix it, >>> (b) document that you should consider periodic manual analyze commands >>> in this situation, or >>> (c) do nothing. >> >>> Thoughts? >> >> The objections to (a) are that it might result in excessive ANALYZE work >> if not done intelligently, and that we haven't got a patch ready anyway. >> I would have liked to get to this for 9.0 but I feel it's a bit late >> now. > > I guess I can't really disagree with that. Should we try to document > this in some way? Proposed patch attached. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Вложения
On Sun, Jun 13, 2010 at 11:47 PM, Robert Haas <robertmhaas@gmail.com> wrote: > Proposed patch attached. Hearing no objections, I have committed this patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
On Fri, Jun 11, 2010 at 10:19 AM, Magnus Hagander <magnus@hagander.net> wrote: >>> Especially if someone has a clue how to do it. The last time I fixed >>> it by runnin repack, but that didn't work this time. I have no clue >>> why it's asking for a file that doesn't exist. >> Does the repo run 'update-server-info' in some hook? > > Yup, it runs after every time it pulls from cvs. Is this still a problem? I was just noticing this thread unceremoniously died, and a long time ago now I remembering discussing a problem involving the Postgres git mirror accumulating packfiles eternally. It seemed that whatever repacking scheme was used would get rid of loose objects, turning them into packs but never consolidate packs. Why not just run 'git gc'? This is probably the only quasi-regularly required maintenance command, so much so that git (I think) runs it from time to time when certain thresholds are passed in modern day. (For a clone-source it is probably a good idea to run it a bit more liberally) fdr