Re: [SQL] how to download linux 7.3 image
On Monday 23 July 2007 01:03, Jean-David Beyer wrote: > Mohd Ghalib Akhtar wrote: > > how to download linux 7.3 image file(means os) ? > If you want a Red Hat looking product, you should consider running the > latest version of Fedora. > You might also want to try CentOs, 'an Enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor.' Their latest release comes with PostgreSQL 8.1 BR, Aarni -- Aarni Ruuhimäki ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] Database Synchronization
Hello, When I am installing slony-I from rpm's available at the following url:http://main.slony.info/downloads/1.2/rpm/ it is giving an error: There are no installable providers of postgresql-slony1-engine. In our system postgresql has been installed through YAST. So when we try to install and configure slony-I through source, it gives the message please make sure tp build and install postgresql from the sources first. I am new to both linux and postgres. Please help me in installing and configuring slony-I on my suse linux m/c. Thanks, Jyoti Seth -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Browne Sent: Wednesday, July 18, 2007 8:28 PM To: pgsql-sql@postgresql.org Subject: Re: [SQL] Database Synchronization [EMAIL PROTECTED] (Richard Huxton) writes: > Jyoti Seth wrote: >> Hello , >> I have two postgres databases on different linux servers. Postgres >> database >> on one server has some tables that needs to be synchronized from the other >> postgres database . What should be the best method for this. > > The slony replication package lets you choose what tables you > replicate. On the destination server the tables will be read-only. > > http://www.slony.info/ > > Take a little time to read through the documentation and experiment > with a test system first. It works fine, but it's got a lot of > complicated options. But it is worth noting one thing about the synchronization... Slony-I's strategy is pretty simple: One node is considered the "master," and the other node is forcibly made to conform to what is on the master. If you want to synchronize back and forth (e.g. - multimaster replication of some sort), Slony-I is not suitable... -- "cbbrowne","@","linuxdatabases.info" http://www3.sympatico.ca/cbbrowne/unix.html Culus thinks we should go to trade shows and see how many people we can kill by throwing debian cds at them ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [SQL] The nested view from hell - Restricting a subquerry
Nis Jørgensen <[EMAIL PROTECTED]> writes: >>> Well, the query can be satisfied by looking only at the rows with an >>> order_id matching the invoice_id given. The condition that this is the >>> largest invoice in the group then needs to be checked afterwards. >>> >>> I certainly did not expect the query planner to be able to deduce this, >>> though. >> >> No, that's not true. If you had two records in eg_order with the same >> order_id >> but different invoice_ids then the query would need both records to satisfy >> the query. > > I assume you mean "... then both records are necessary in order to > calculate the results of the query". This does not contradict what I wrote. Sorry I meant, "the query as written can not be satisfied by looking only at the rows with the specified invoice_id". > SELECT order_id, > max(order_view.invoice_id), > sum(order_view.mileage) > FROM(SELECT order_id,invoice_id, 0 as mileage FROM eg_order > UNION > SELECT order_id, 0, mileage FROM eg_order_line) > order_view GROUP BY order_view.order_id; > > This is then restricted on max(invoice_id) > > As far as I can tell, these steps produce the correct results (without > the later information about primary keys provided by Bryce) > > INPUT: my_invoice_id > > 1. Look up all order_ids for which (order_id,my_invoice_id) appear in > eg_orders > > 2. Find all rows (in both branches of the UNION) with these id_s > > 3. Group the rows, and calculate max(invoice_id) > > 4. Filter the result rows on max(invoice_id) = my_invoice_id. So here's a hypothetical data set for which this algorithm fails: order_idinvoice_id mileage 1 1 100 1 2 100 Your algorithm would produce order_idmax(invoice_id) sum(mileage) 1 1 100 Whereas the correct output would be to output no records at all. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [SQL] The nested view from hell - Restricting a subquerry
Gregory Stark skrev: >> 1. Look up all order_ids for which (order_id,my_invoice_id) appear in >> eg_orders >> >> 2. Find all rows (in both branches of the UNION) with these id_s >> >> 3. Group the rows, and calculate max(invoice_id) >> >> 4. Filter the result rows on max(invoice_id) = my_invoice_id. > > So here's a hypothetical data set for which this algorithm fails: > > order_id invoice_id mileage > > 1 1 100 > 1 2 100 > > Your algorithm would produce > > order_id max(invoice_id) sum(mileage) > > 1 1 100 > > Whereas the correct output would be to output no records at all. (I assume you are using "1" as the parameter to the query). You seem to have interpreted one or more of the steps differently than I intended them. I have tried to clarify (resorting to SQL for the first step). 1. SELECT DISTINCT order_id FROM eg_order WHERE invoice_id = my_invoice_id 2. Find all rows (in both branches of the UNION) with these order_ids. 3. Group the rows on order_id, and calculate max(invoice_id) 4. Filter the result rows on max(invoice_id) = my_invoice_id. Thus, step 1 produces order_id -- 1 step 2 produces order_id invoice_id mileage 1 1 100 1 2 100 Step 3 produces order_id max(invoice_id) sum(mileage) 1 2 200 Step 4 eliminates this row, since it does not satisfy the criteria. Nis ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [SQL] The nested view from hell - Restricting a subquerry
"Gregory Stark" <[EMAIL PROTECTED]> writes: > Nis Jørgensen <[EMAIL PROTECTED]> writes: > >> 1. Look up all order_ids for which (order_id,my_invoice_id) appear in >> eg_orders >> >> 2. Find all rows (in both branches of the UNION) with these id_s Oh, did you mean look up the order_ids for which there was at least one record with the invoice_id specified, then look up all records with those order_ids regardless of invoice_id? That would work but as you say it would be hard to tell whether it will be any faster than just processing all the order_ids. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [SQL] Database Synchronization
On Mon, Jul 23, 2007 at 02:55:21PM +0530, Jyoti Seth wrote: > In our system postgresql has been installed through YAST. So when we try to > install and configure slony-I through source, it gives the message please > make sure tp build and install postgresql from the sources first. > You _might_ be able to get this to work by installing whatever extra bits the YAST installation tool offers (probably something with -dev- or -src- in it). A -- Andrew Sullivan | [EMAIL PROTECTED] Users never remark, "Wow, this software may be buggy and hard to use, but at least there is a lot of code underneath." --Damien Katz ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
