Обсуждение: Row counts for large tables cause temporary hang
Dear list, Just recently downloaded Pgadmin III 1.0.2 for win32, and am using it against (native) win32 Pg 7.5dev (to get a nicer client interface) - I am very impressed with Pgadmin, it rocks! The only gripe I have is the seemingly automatic count on tables as they are clicked on - this hangs Pgadmin for minutes on one of the big tables (10 million rows). By way of a suggestion, I wondered about this logic : - analyze the table instead of counting it - if estimated count is < (configurable limit), then count for real, otherwise use the estimate. Apologies if you guys have done something like this, and my using 7.5dev is confusing things :-) regards Mark
Hi Mark, > -----Original Message----- > From: Mark Kirkwood [mailto:markir@paradise.net.nz] > Sent: 28 April 2004 08:00 > To: pgadmin-hackers@postgresql.org > Subject: [pgadmin-hackers] Row counts for large tables cause > temporary hang > > Dear list, > > Just recently downloaded Pgadmin III 1.0.2 for win32, and am > using it against (native) win32 Pg 7.5dev (to get a nicer > client interface) - I am very impressed with Pgadmin, it rocks! Thanks :-) > The only gripe I have is the seemingly automatic count on > tables as they are clicked on - this hangs Pgadmin for > minutes on one of the big tables (10 million rows). Please look under File -> Options, and on the Query tab you can set the threshold value for the 'estimated' rows above which 'real' rows are not counted. You need to analyse your database periodically to ensure the estimated value stays fairly accurate (this is recommended anyway). Regards, Dave.
Oops...missed that one (and it's in an obvious place too....). Thanks, I will set it! regards Mark Dave Page wrote: > >Please look under File -> Options, and on the Query tab you can set the >threshold value for the 'estimated' rows above which 'real' rows are not >counted. You need to analyse your database periodically to ensure the >estimated value stays fairly accurate (this is recommended anyway). > >
Hmm ... it is set already (count rows if estimated < 2000) Checking in the properties window for that table concerned shows : rows estimated = 1 rows counted = 10000000 however reltuples in pg_class shows 1e07, so it looks like pgadmin is not representing the "real" datatype correctly (maybe a 7,5 thing - tho the datatype of pg_class is the same in 7.4). Any ideas? I will try the same test on my home system (Freebsd 4.9) with Pg 7.4 (assuming I can get pgadmin to build on 4.9...) regards Mark ) Mark Kirkwood wrote: > Oops...missed that one (and it's in an obvious place too....). > Thanks, I will set it! > > regards > > Mark > > Dave Page wrote: > >> >> Please look under File -> Options, and on the Query tab you can set the >> threshold value for the 'estimated' rows above which 'real' rows are not >> counted. You need to analyse your database periodically to ensure the >> estimated value stays fairly accurate (this is recommended anyway). >> >> > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > >
Mark Kirkwood wrote: > Hmm ... it is set already (count rows if estimated < 2000) > > Checking in the properties window for that table concerned shows : > > rows estimated = 1 > rows counted = 10000000 > > however reltuples in pg_class shows 1e07, so it looks like pgadmin is > not representing the "real" datatype correctly (maybe a 7,5 thing - > tho the datatype of pg_class is the same in 7.4). Any ideas? Known problem, use 1.1.0. Regards, Andreas
Andreas Pflug wrote: > Mark Kirkwood wrote: > >> Hmm ... it is set already (count rows if estimated < 2000) >> >> Checking in the properties window for that table concerned shows : >> >> rows estimated = 1 >> rows counted = 10000000 >> >> however reltuples in pg_class shows 1e07, so it looks like pgadmin is >> not representing the "real" datatype correctly (maybe a 7,5 thing - >> tho the datatype of pg_class is the same in 7.4). Any ideas? > > > > Known problem, use 1.1.0. > > Thanks.