Re: [PERFORM] [GENERAL] how to get accurate values in pg_statistic

2003-09-11 Thread scott.marlowe
On Thu, 11 Sep 2003, Tom Lane wrote: > Christopher Browne <[EMAIL PROTECTED]> writes: > > The "right answer" for most use seems likely to involve: > > a) Getting an appropriate number of bins (I suspect 10 is a bit > > small, but I can't justify that mathematically), and > > I suspect that a

Re: [PERFORM] Upgrade Woes

2003-09-11 Thread aturner
In the performance case the machine was running RedHat AS 2.1. I have posted the database schema at (obtained from pg_dump -s): http://serverbeach.plexq.com/~aturner/schema.sql The time to run all the stats procedures dropped through the floor. refresh_hourly_iud, adl_hourly_iud, rebuild_dail

Re: [PERFORM] [GENERAL] how to get accurate values in pg_statistic

2003-09-11 Thread Christopher Browne
[EMAIL PROTECTED] ("scott.marlowe") writes: > On Thu, 11 Sep 2003, Tom Lane wrote: > >> Christopher Browne <[EMAIL PROTECTED]> writes: >> > The "right answer" for most use seems likely to involve: >> > a) Getting an appropriate number of bins (I suspect 10 is a bit >> > small, but I can't just

Re: [PERFORM] Upgrade Woes

2003-09-11 Thread Jeff
On Thu, 11 Sep 2003, [EMAIL PROTECTED] wrote: > > The Vacuum full is performed once at the end of the whole job. > have you also tried vacuum analyze periodically - it does not lock the table and can help quite a bit? still odd why it would be that much slower between those versions. -- Jeff Tro

Re: [PERFORM] Upgrade Woes

2003-09-11 Thread Tom Lane
[EMAIL PROTECTED] writes: > As for 7.3.3, the project in question suffered a 10x performance > degredation on 7.3.3 which went away when we rolled back to 7.3.2. I would like to pursue that report and find out why. I've just gone through the CVS logs between 7.3.2 and 7.3.3, and I don't see any c

Re: [PERFORM] Upgrade Woes

2003-09-11 Thread aturner
Thanks for the URL, I went through postgresql.conf and made some modifications to the config based on information therein. I will have to wait and see how it affects things, as I won't know for a week or so. Select time has never been a problem, the DB has always been very fast, it's the inser

Re: [PERFORM] Reading data in bulk - help?

2003-09-11 Thread Christopher Kings-Lynne
> You want values *much* higher than that. How much RAM do you have? See: > http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html > http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html Now THAT is a remarkable document! I vote for putting that information into the Po

Re: [PERFORM] [GENERAL] how to get accurate values in pg_statistic (continued)

2003-09-11 Thread Tom Lane
Christopher Browne <[EMAIL PROTECTED]> writes: > The "right answer" for most use seems likely to involve: > a) Getting an appropriate number of bins (I suspect 10 is a bit > small, but I can't justify that mathematically), and I suspect that also, but I don't have real evidence for it either.

Re: [PERFORM] [GENERAL] how to get accurate values in pg_statistic (continued)

2003-09-11 Thread Christopher Browne
[EMAIL PROTECTED] (Bruce Momjian) writes: > Tom Lane wrote: >> Mary Edie Meredith <[EMAIL PROTECTED]> writes: >> > Stephan Szabo kindly responded to our earlier queries suggesting >> > we look at default_statistics_target and ALTER TABLE ALTER COLUMN >> > SET STATISTICS. >> >> > These determine th