Re: [HACKERS] Problem with a rule on upgrade to v7.1.1

2001-05-12 Thread Tom Lane
Jon Lapham <[EMAIL PROTECTED]> writes: > PS: (Talking *way* above my head now) Would be possible to have > EXPLAIN flag this type of problem? Remember, the EXPLAIN output for > 7.1RC1 and 7.1.1 were identical. Yeah, because EXPLAIN doesn't show the individual qual clauses attached to each plan

Re: [HACKERS] Problem with a rule on upgrade to v7.1.1

2001-05-11 Thread Jon Lapham
Tom- Thanks for the detective work. This makes perfect sense now, and explains the radically different behaviour between 7.1RC1 and 7.1.1. I will change my rules to not have to depend on Pg choosing which WHERE clause to evaluate first. -Jon PS: (Talking *way* above my head now) Would be p

Re: [HACKERS] Problem with a rule on upgrade to v7.1.1

2001-05-11 Thread Tom Lane
Jon Lapham <[EMAIL PROTECTED]> writes: > But, there is definitely something wrong here, b/c the rule that is > causing this *should* only need to run the subselect [SELECT count(*) FROM > tplantorgan WHERE tplantid=NEW.tplantid AND sampleid<>NEW.sampleid AND > active='t'] one time! My understa

Re: [HACKERS] Problem with a rule on upgrade to v7.1.1

2001-05-11 Thread Tom Lane
Jon Lapham <[EMAIL PROTECTED]> writes: > I didn't do Pgv7.0.3 b/c I think it may be unnecessary > since 7.1RC1 doesn't show this problem, while 7.1.1 does. But, if you > really think it necessary, I will repeat his using 7.0.3. No, that seems like useless work. > 1) As usual, the 7.1RC1 returns

Re: [HACKERS] Problem with a rule on upgrade to v7.1.1

2001-05-11 Thread Jon Lapham
On Thu, May 10, 2001 at 06:44:39PM -0400, Tom Lane wrote: > Next question: do you still have your 7.0.* DB up? Can you get an > EXPLAIN that shows how it did it (on the real tables)? Tom- Okay. I started from a clean slate, by recompiling both Pgv7.1.1 and Pgv7.1RC1, initdb'ing each (after app

Re: [HACKERS] Problem with a rule on upgrade to v7.1.1

2001-05-10 Thread Jon Lapham
Tom Lane <[EMAIL PROTECTED]> escreveu: > [snip] > Next question: do you still have your 7.0.* DB up? Can you get an > EXPLAIN that shows how it did it (on the real tables)? Setting it up right now... unfortunately I will have to do a recompile / reinstall as I have rm -r'ed the old versions. So

Re: [HACKERS] Problem with a rule on upgrade to v7.1.1

2001-05-10 Thread Tom Lane
Jon Lapham <[EMAIL PROTECTED]> writes: >> Uh, have you VACUUM ANALYZEd yet? Those EXPLAIN numbers look >> suspiciously like default statistics ... > Nope, forgot to on the little demonstration tables I made. I tacked the > post-VACUUM ANALYZE explain results (they look much better) at the end

Re: [HACKERS] Problem with a rule on upgrade to v7.1.1

2001-05-10 Thread Jon Lapham
On Thu, May 10, 2001 at 05:56:11PM -0400, Tom Lane wrote: > Jon Lapham <[EMAIL PROTECTED]> writes: > > Yesterday I upgraded my database from Pg v7.1RC1 to v7.1.1. Since this > > upgrade, I have been having unbelievable performance problems with updates > > to a particular table, and I've tracked

Re: [HACKERS] Problem with a rule on upgrade to v7.1.1

2001-05-10 Thread Tom Lane
Jon Lapham <[EMAIL PROTECTED]> writes: > Yesterday I upgraded my database from Pg v7.1RC1 to v7.1.1. Since this > upgrade, I have been having unbelievable performance problems with updates > to a particular table, and I've tracked the problem down to a rule within > that table. Uh, have you VACU

[HACKERS] Problem with a rule on upgrade to v7.1.1

2001-05-10 Thread Jon Lapham
Hello all- Yesterday I upgraded my database from Pg v7.1RC1 to v7.1.1. Since this upgrade, I have been having unbelievable performance problems with updates to a particular table, and I've tracked the problem down to a rule within that table. I've enclosed a simple case study at the end of this