| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | postgres performance list <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Yet another abort-early plan disaster on 9.3 |
| Date: | 2014-12-10 01:46:34 |
| Message-ID: | 5487A5FA.8080603@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
On 12/05/2014 08:04 AM, Simon Riggs wrote:
> On 6 December 2014 at 00:45, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>
>> Neat -- got any test cases (would this have prevented OP's problem)?
>
> No test case was posted, so I am unable to confirm.
>
> A test case I produced that appears to be the same issue is fixed.
>
> I await confirmation from the OP.
>
So that's proprietary/confidential data. However, the company involved
has a large testbed and I could test their data using a patched version
of Postgres. In 3 months their data distribution has drifted, so I'll
need to do some work to recreate the original bad plan circumstances.
I'll keep you posted on how the patch works for that setup.
It would be great to come up with a generic/public test for a bad
abort-early situation. Ideas?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2014-12-10 02:03:33 | Re: B-Tree support function number 3 (strxfrm() optimization) |
| Previous Message | Alvaro Herrera | 2014-12-10 01:04:05 | Re: Small TRUNCATE glitch |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2014-12-10 02:09:01 | Re: Yet another abort-early plan disaster on 9.3 |
| Previous Message | Strahinja Kustudić | 2014-12-09 23:28:47 | 8xIntel S3500 SSD in RAID10 on Dell H710p |