Re: [SQL] Re: [HACKERS] Re: INSERT/UPDATE waiting (another example)

> 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@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026