[DOCS] Moving FAQs to PgFoundry
Hi Bruce, As you know, Peter moved the translation stuff to PgFoundry. As a translator, I'm happy to commit to there since I can do it whenever I want -- better than sending to the list each time I update. What about doing the same for FAQ translations? We may have a chance to assign several translators to each FAQ and we may easily keep them up2date. The website can be configured to pull them from CVS. I can assist you during this moving process, if you want. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PL/php, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] Moving FAQs to PgFoundry
> Hi Bruce, > > As you know, Peter moved the translation stuff to PgFoundry. > As a translator, I'm happy to commit to there since I can do > it whenever I want -- better than sending to the list each > time I update. > > What about doing the same for FAQ translations? We may have a > chance to assign several translators to each FAQ and we may > easily keep them up2date. The website can be configured to > pull them from CVS. > > I can assist you during this moving process, if you want. If we're moving it to a different cvs, perhaps we should consider moving them directly into the website cvs? //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] Moving FAQs to PgFoundry
Hi, On Mon, 2005-12-12 at 15:36 +0100, Magnus Hagander wrote: > > What about doing the same for FAQ translations? We may have a > > chance to assign several translators to each FAQ and we may > > easily keep them up2date. The website can be configured to > > pull them from CVS. > > > > I can assist you during this moving process, if you want. > > If we're moving it to a different cvs, perhaps we should consider moving > them directly into the website cvs? This is not directly related with the website development I think. They are also in main source code. So a seperate CVS would be cool IMHO, like translations as I wrote before. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PL/php, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] Moving FAQs to PgFoundry
> > > What about doing the same for FAQ translations? We may > have a chance > > > to assign several translators to each FAQ and we may easily keep > > > them up2date. The website can be configured to pull them from CVS. > > > > > > I can assist you during this moving process, if you want. > > > > If we're moving it to a different cvs, perhaps we should consider > > moving them directly into the website cvs? > > This is not directly related with the website development I > think. They are also in main source code. So a seperate CVS > would be cool IMHO, like translations as I wrote before. No, but it is directly related to website content. If we'd move them to a different cvs (be that web or separate project), I'd expect them to go away from main cvs? Is there any actual point in keeping them in more than one place? //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] Moving FAQs to PgFoundry
Hi, On Mon, 2005-12-12 at 15:56 +0100, Magnus Hagander wrote: > If we'd move them to a different cvs (be that web or separate project), > I'd expect them to go away from main cvs? Is there any actual point in > keeping them in more than one place? As done in translation project, the main website will pull from the other CVS. Here we need to mail to Bruce to update the FAQs, etc. Now we will be able to commit to another CVS. -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PL/php, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] Moving FAQs to PgFoundry
Devrim GUNDUZ wrote: > Hi, > > On Mon, 2005-12-12 at 15:56 +0100, Magnus Hagander wrote: > > > If we'd move them to a different cvs (be that web or separate project), > > I'd expect them to go away from main cvs? Is there any actual point in > > keeping them in more than one place? > > As done in translation project, the main website will pull from the > other CVS. Here we need to mail to Bruce to update the FAQs, etc. Now we > will be able to commit to another CVS. The only trick is that release packaging will need to pull from that CVS. I think right now Peter pulls the *.po files manually from there to the source CVS, right? -- Bruce Momjian| http://candle.pha.pa.us [email protected] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] Moving FAQs to PgFoundry
On Mon, 12 Dec 2005, Magnus Hagander wrote: What about doing the same for FAQ translations? We may have a chance to assign several translators to each FAQ and we may easily keep them up2date. The website can be configured to pull them from CVS. I can assist you during this moving process, if you want. If we're moving it to a different cvs, perhaps we should consider moving them directly into the website cvs? This is not directly related with the website development I think. They are also in main source code. So a seperate CVS would be cool IMHO, like translations as I wrote before. No, but it is directly related to website content. If we'd move them to a different cvs (be that web or separate project), I'd expect them to go away from main cvs? Is there any actual point in keeping them in more than one place? Stupid question here, but Devrim's idea is that ppl can be easily added to CVS with write permissions to update/modify the various translations, without having to submit patches ... Do you *really* want a bunch of ppl with write access to the main web site CVS? :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] Moving FAQs to PgFoundry
On Mon, 12 Dec 2005, Bruce Momjian wrote: Devrim GUNDUZ wrote: Hi, On Mon, 2005-12-12 at 15:56 +0100, Magnus Hagander wrote: If we'd move them to a different cvs (be that web or separate project), I'd expect them to go away from main cvs? Is there any actual point in keeping them in more than one place? As done in translation project, the main website will pull from the other CVS. Here we need to mail to Bruce to update the FAQs, etc. Now we will be able to commit to another CVS. The only trick is that release packaging will need to pull from that CVS. I think right now Peter pulls the *.po files manually from there to the source CVS, right? Actually, if I know where to pull from, adding that sort of thing to the build scripts isn't that hard ... in fact, I've suggested this in so far as pulling in stuff like JDBC into the main tar ball as well, where we could pull in a specific 'tag branch' when building ... just means that the JDBC folks, as an example, would have to create a tag that we could use for that specific purpose ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] [HACKERS] Please Help: PostgreSQL Query Optimizer
Anjan, > But, in PostgreSQL all costs are scaled relative to a page fetch. If we > make both sequential_page_fetch_cost and random_page_cost to "1", then we > need to increase the various cpu_* paramters by multiplying the default > values with appropriate Scaling Factor. Now, we need to determine this > Scaling Factor. I see, so you're saying that because the real cost of a page fetch has decreased, the CPU_* costs should increase proportionally because relative to the real costs of a page fetch they should be higher? That makes a sort of sense. The problem that you're going to run into is that currently we have no particularly reason to believe that the various cpu_* costs are more than very approximately correct as rules of thumb. So I think you'd be a lot better off trying to come up with some means of computing the real cpu costs of each operation, rather than trying to calculate a multiple of numbers which may be wrong in the first place. I know that someone on this list was working on a tool to digest EXPLAIN ANALYZE results and run statistics on them. Can't remember who, though. Also, I'm still curious on how you're handling shared_mem, work_mem and maintenance_mem. You didn't answer last time. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
