Thread: Fwd: Re: Weird trouble with select
-------- Original Message -------- Subject: Re: [GENERAL] Weird trouble with select Date: Tue, 29 Jun 2010 09:13:14 -0500 From: erobles <erobles@sensacd.com.mx> Organization: SENSA Control Digital To: Joshua Tolley <eggyknap@gmail.com> On 06/29/2010 08:59 AM, Joshua Tolley wrote: > On Tue, Jun 29, 2010 at 08:44:35AM -0500, erobles wrote: > >> Hi! >> >> I have 3 pc's: >> pc 'A' with postgres 7.2 running >> pc 'B' and 'C' connected to 'A' >> > You should upgrade as quickly as possible. 7.2 is ancient. Even 8.1 will hit > end-of-life soon. > We are testing postgres 8.3.11 to detect any problem when we migrate from 7.2 :-) >> if i made the next query on 'B' or 'C' : "select * from detail with >> id=72"; takes too long time to return the data, near of 10 minutes >> more or less. >> if i made the next query on 'B' or 'C' : "select * from detail with >> id=71", or whatever value in id , the data are returned immediatly. >> >> if i made the next query on 'A' (postgres server): "select * from >> detail with id=72", the data are returned immediatly. >> > > I wonder if you're just hitting caching effects, and the different client > hosts are confusing the issue. > If you issue the query from one machine > multiple times, does it reliably take forever the first time, and go quickly > afterward? > no, doesn't. This only works fine with a pc diferent to 'B' or 'C' if the query is executed many times only on 'B' the query always fail for id=72 with another value works fine.
On Tuesday 29 June 2010 7:22:56 am erobles wrote: > -------- Original Message -------- > Subject: Re: [GENERAL] Weird trouble with select > Date: Tue, 29 Jun 2010 09:13:14 -0500 > From: erobles <erobles@sensacd.com.mx> > Organization: SENSA Control Digital > To: Joshua Tolley <eggyknap@gmail.com> > > On 06/29/2010 08:59 AM, Joshua Tolley wrote: > > On Tue, Jun 29, 2010 at 08:44:35AM -0500, erobles wrote: > >> Hi! > >> > >> I have 3 pc's: > >> pc 'A' with postgres 7.2 running > >> pc 'B' and 'C' connected to 'A' > > > > You should upgrade as quickly as possible. 7.2 is ancient. Even 8.1 will > > hit end-of-life soon. > > We are testing postgres 8.3.11 to detect any problem when we migrate > from 7.2 :-) > > >> if i made the next query on 'B' or 'C' : "select * from detail with > >> id=72"; takes too long time to return the data, near of 10 minutes > >> more or less. > >> if i made the next query on 'B' or 'C' : "select * from detail with > >> id=71", or whatever value in id , the data are returned immediatly. > >> > >> if i made the next query on 'A' (postgres server): "select * from > >> detail with id=72", the data are returned immediatly. > > > > I wonder if you're just hitting caching effects, and the different > > client hosts are confusing the issue. > > If you issue the query from one machine > > multiple times, does it reliably take forever the first time, and go > > quickly afterward? > > no, doesn't. > This only works fine with a pc diferent to 'B' or 'C' > if the query is executed many times only on 'B' the query always fail > for id=72 with another value works fine. How many results are being returned for id=72 vs other ids? How are 'B' and 'C' connecting to 'A'; psql,JDBC,ODBC ? Are you sure the clients are all connecting to the same database? -- Adrian Klaver adrian.klaver@gmail.com
> >>>> Hi! >>>> >>>> I have 3 pc's: >>>> pc 'A' with postgres 7.2 running >>>> pc 'B' and 'C' connected to 'A' >>>> >>> You should upgrade as quickly as possible. 7.2 is ancient. Even 8.1 will >>> hit end-of-life soon. >>> >> We are testing postgres 8.3.11 to detect any problem when we migrate >> from 7.2 :-) >> >> >>>> if i made the next query on 'B' or 'C' : "select * from detail with >>>> id=72"; takes too long time to return the data, near of 10 minutes >>>> more or less. >>>> if i made the next query on 'B' or 'C' : "select * from detail with >>>> id=71", or whatever value in id , the data are returned immediatly. >>>> >>>> if i made the next query on 'A' (postgres server): "select * from >>>> detail with id=72", the data are returned immediatly. >>>> >>> I wonder if you're just hitting caching effects, and the different >>> client hosts are confusing the issue. >>> If you issue the query from one machine >>> multiple times, does it reliably take forever the first time, and go >>> quickly afterward? >>> >> no, doesn't. >> This only works fine with a pc diferent to 'B' or 'C' >> if the query is executed many times only on 'B' the query always fail >> for id=72 with another value works fine. >> > Hi!, thanks for your answer > How many results are being returned for id=72 vs other ids? > the tuples returned for id=72 are 91 (is too short :-( ), for id=71 are 94 for id=10 are 44. > How are 'B' and 'C' connecting to 'A'; psql,JDBC,ODBC ? > the connection is realized by psql. > Are you sure the clients are all connecting to the same database? > Yes i sure. Even check the PGUSER, PGDATABASE and PGHOST and those varables are well setting.
On Tuesday 29 June 2010 7:47:32 am erobles wrote: > > Hi!, thanks for your answer > > > How many results are being returned for id=72 vs other ids? > > the tuples returned for id=72 are 91 (is too short :-( ), for id=71 > are 94 for id=10 are 44. > > > How are 'B' and 'C' connecting to 'A'; psql,JDBC,ODBC ? > > the connection is realized by psql. > > > Are you sure the clients are all connecting to the same database? > > Yes i sure. Even check the PGUSER, PGDATABASE and PGHOST and those > varables are well setting. At this point I do not have a clue as to what could be causing the difference in behavior :( -- Adrian Klaver adrian.klaver@gmail.com
On 06/29/2010 10:19 AM, Adrian Klaver wrote: > On Tuesday 29 June 2010 7:47:32 am erobles wrote: > >> Hi!, thanks for your answer >> >> >>> How many results are being returned for id=72 vs other ids? >>> >> the tuples returned for id=72 are 91 (is too short :-( ), for id=71 >> are 94 for id=10 are 44. >> >> >>> How are 'B' and 'C' connecting to 'A'; psql,JDBC,ODBC ? >>> >> the connection is realized by psql. >> >> >>> Are you sure the clients are all connecting to the same database? >>> >> Yes i sure. Even check the PGUSER, PGDATABASE and PGHOST and those >> varables are well setting. >> > At this point I do not have a clue as to what could be causing the difference in > behavior :( > > Yes, me too! :-(