Agree with Thom,
I also had the same problem back then when I was migrate from old servers to
new server.
After I vacuum the DB at the new servers the result back to normal.
Rgrds
Sent from my BlackBerry®powered by AyahNaima
-Original Message-
From: Thom Brown
Date: Fri, 14 May 2010
On May 14, 2010, at 3:52 PM, Scott Marlowe wrote:
> 2010/5/14 Piotr Legiecki :
>> So what is the problem? My simple 'benchmarks' I have done with pgAdmin in
>> spare time.
>>
>> pgAdmin is the latest 1.8.2 on both D and E.
>> Using pgAdmin on my (D) computer I have run SELECT * from some_table;
2010/5/14 Piotr Legiecki :
> So what is the problem? My simple 'benchmarks' I have done with pgAdmin in
> spare time.
>
> pgAdmin is the latest 1.8.2 on both D and E.
> Using pgAdmin on my (D) computer I have run SELECT * from some_table; and
> noted the execution time on both A and B servers:
So,
2010/5/14 Piotr Legiecki
> Hi
>
> I have a situation at my work which I simply don't understand and hope
> that here I can find some explanations.
>
> What is on the scene:
> A - old 'server' PC AMD Athlon64 3000+, 2GB RAM, 1 ATA HDD 150GB, Debian
> etch, postgresql 8.1.19
> B - new server HP DL
Hi
I have a situation at my work which I simply don't understand and hope
that here I can find some explanations.
What is on the scene:
A - old 'server' PC AMD Athlon64 3000+, 2GB RAM, 1 ATA HDD 150GB, Debian
etch, postgresql 8.1.19
B - new server HP DL 360, 12GB RAM, Intel Xeon 8 cores CPU,
On Wed, May 12, 2010 at 7:26 PM, Kevin Grittner wrote:
> venu madhav wrote:
>
> >> > If the records are more in the interval,
> >>
> >> How do you know that before you run your query?
> >>
> > I calculate the count first.
>
> This and other comments suggest that the data is totally static
> whil
On Wed, May 12, 2010 at 5:25 PM, Kevin Grittner wrote:
> venu madhav wrote:
>
> >>> AND e.timestamp >= '1270449180'
> >>> AND e.timestamp < '1273473180'
> >>> ORDER BY.
> >>> e.cid DESC,
> >>> e.cid DESC
> >>> limit 21
> >>> offset 10539780
>
> > The second column acts as a secondary key for sor
On Wed, May 12, 2010 at 3:20 AM, Kevin Grittner wrote:
> venu madhav wrote:
>
> > When I try to get the last twenty records from the database, it
> > takes around 10-15 mins to complete the operation.
>
> Making this a little easier to read (for me, at least) I get this:
>
> select e.cid, times
On Wed, May 12, 2010 at 3:22 AM, Shrirang Chitnis <
shrirang.chit...@hovservices.com> wrote:
> Venu,
>
> For starters,
>
> 1) You have used the e.cid twice in ORDER BY clause.
>
[Venu] Actually the second cid acts as a secondary sort order if any other
column in the table is used for sorting. In t
On Wed, May 12, 2010 at 3:17 AM, Jorge Montero <
jorge_mont...@homedecorators.com> wrote:
> First, are you sure you are getting autovacuum to run hourly? Autovacuum
> will only vacuum when certain configuration thresholds are reached. You can
> set it to only check for those thresholds every so o
Kevin Grittner wrote:
Piotr Legiecki wrote:
Why there is no difference in database speed between those two
machines?
Could you post the contents of the postgresql.conf files for both
(stripped of comments) and explain what you're using for your
benchmarks? In particular, it would
2010/5/14 Piotr Legiecki :
> Hi
> The goal: migrate postgresql from A to B.
>
> Simple and works fine (using pg_dump, psql -d dbname
> So what is the problem? My simple 'benchmarks' I have done with pgAdmin
> in spare time.
>
> pgAdmin is the latest 1.8.2 on both D and E.
> Using pgAdmin on my (D)
Piotr Legiecki wrote:
> Why there is no difference in database speed between those two
> machines?
Could you post the contents of the postgresql.conf files for both
(stripped of comments) and explain what you're using for your
benchmarks? In particular, it would be interesting to know how man
Hi
I have a situation at my work which I simply don't understand and hope
that here I can find some explanations.
What is on the scene:
A - old 'server' PC AMD Athlon64 3000+, 2GB RAM, 1 ATA HDD 150GB, Debian
etch, postgresql 8.1.19
B - new server HP DL 360, 12GB RAM, Intel Xeon 8 cores CPU, fas
14 matches
Mail list logo
