From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Wayne Piekarski <wayne(at)senet(dot)com(dot)au> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org, pgsql-sql(at)postgreSQL(dot)org |
Subject: | Re: [SQL] Re: [HACKERS] Re: INSERT/UPDATE waiting (another example) |
Date: | 1999-05-09 11:14:17 |
Message-ID: | 199905091114.HAA08218@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
> The whole thing runs 24 hours a day, 7 days a week. Most of the tables
> rarely get vacuumed (they have tens of thousands of rows and only inserts
> get done to them - the optimiser makes good choices for most of these) -
> however we have 5 tables which get vacuum at midnight each day, we drop
> all the indexes, vacuum, then recreate. If we don't do the index thing,
> the vacuum can take tens of minutes, which is not acceptable - the tables
> contain about 20000 rows, each of which gets updated about 3 times during
> the day. I sent an email a while back about vacuum performance, and this
> hack is the only way around it.
6.5 beta speeds up vacuuming with existing indexes, thanks to Vadim.
Also, accessing during vacuuming may be better too.
> While I'm asking some questions here, I should tell you about some of the
> other wierd things I've encountered, many of them are related to shared
> memory and hash tables, which is making me think more and more that all
> the problems I am having are somehow related.
6.5 beta has some _major_ hash fixes. We always knew there were hash
problems, but now Tom has fixed many of them.
> I would assume that the above one which uses indexes would be a lot
> better, but why did the optimiser chose the seq scan - do the indexes help
> when doing joins and at the same time all rows are being returned back? I
> understand that the optimiser will choose not to use indexes if it feels
> that it will return most of the rows anyway and so a seq scan is better.
6.5 beta also has a faster and smarter optimizer.
It may be wise for you to test 6.5beta to see how many problems we fix.
--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-05-09 11:53:57 | Re: [ADMIN] maximum attribute record. |
Previous Message | Hannu Krosing | 1999-05-09 10:56:24 | Re: [HACKERS] ODMG interface |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-05-09 12:02:25 | Re: [SQL] keeping OID's when copying table |
Previous Message | Wayne Piekarski | 1999-05-09 08:08:42 | Re: [HACKERS] Re: INSERT/UPDATE waiting (another example) |