On Wed, Jul 10, 2019 at 09:11:41AM -0700, Ashwin Agrawal wrote:
> Will post patch for the tool, once I get in little decent shape.
That would be nice! We may be able to get something into v13 this way
then.
--
Michael
signature.asc
Description: PGP signature
On Wed, Jul 10, 2019 at 6:46 AM Tom Lane wrote:
> Michael Paquier writes:
> > On Wed, Jul 10, 2019 at 12:51:28PM +0530, Amit Kapila wrote:
> >> It would be good if we can come up with something like that. It will
> >> be helpful for zheap, where in some cases we get different row
> >> ordering
Michael Paquier writes:
> On Wed, Jul 10, 2019 at 12:51:28PM +0530, Amit Kapila wrote:
>> It would be good if we can come up with something like that. It will
>> be helpful for zheap, where in some cases we get different row
>> ordering due to in-place updates. As of now, we try to add Order By
On Wed, Jul 10, 2019 at 12:40 AM Michael Paquier
wrote:
> On Wed, Jul 10, 2019 at 12:51:28PM +0530, Amit Kapila wrote:
> > It would be good if we can come up with something like that. It will
> > be helpful for zheap, where in some cases we get different row
> > ordering due to in-place
On Wed, Jul 10, 2019 at 12:51:28PM +0530, Amit Kapila wrote:
> It would be good if we can come up with something like that. It will
> be helpful for zheap, where in some cases we get different row
> ordering due to in-place updates. As of now, we try to add Order By
> or do some extra magic to
On Wed, Jul 10, 2019 at 10:12 AM Michael Paquier wrote:
>
> On Tue, Jul 09, 2019 at 11:54:29AM -0700, Melanie Plageman wrote:
> > It might be worth post-processing results files to ignore row ordering
> > in some cases to allow for easier comparison. Has this been proposed
> > in the past?
>
>
On Tue, Jul 09, 2019 at 11:54:29AM -0700, Melanie Plageman wrote:
> It might be worth post-processing results files to ignore row ordering
> in some cases to allow for easier comparison. Has this been proposed
> in the past?
Not that I recall.
--
Michael
signature.asc
Description: PGP signature
On Mon, Jul 8, 2019 at 12:21 PM Tom Lane wrote:
> The point of regressplans.sh is to see if anything goes seriously
> wrong when forcing non-default plan choices --- seriously wrong being
> defined as crashes or semantically wrong answers. It's not expected
> that the regression tests will
On Tue, Jul 09, 2019 at 03:04:27PM +1200, Thomas Munro wrote:
> It's my mistake. I'll fix it later today.
Thanks!
--
Michael
signature.asc
Description: PGP signature
On Tue, Jul 9, 2019 at 2:45 PM Michael Paquier wrote:
> On Tue, Jul 09, 2019 at 02:30:51PM +1200, Thomas Munro wrote:
> > Yeah. I had obviously never noticed that test script. +1 for just
> > enabling hash joins the top of join_hash.sql in 12+, and the
> > equivalent section in 11's join.sql
Michael Paquier writes:
> On Tue, Jul 09, 2019 at 02:30:51PM +1200, Thomas Munro wrote:
>> Yeah. I had obviously never noticed that test script. +1 for just
>> enabling hash joins the top of join_hash.sql in 12+, and the
>> equivalent section in 11's join.sql (which is luckily at the end of
>>
On Tue, Jul 09, 2019 at 02:30:51PM +1200, Thomas Munro wrote:
> Yeah. I had obviously never noticed that test script. +1 for just
> enabling hash joins the top of join_hash.sql in 12+, and the
> equivalent section in 11's join.sql (which is luckily at the end of
> the file).
Right, I did not
On Tue, Jul 9, 2019 at 2:22 PM Tom Lane wrote:
> Thomas Munro writes:
> > Based on a suggestion from Andres (if I recall correctly), I wrapped
> > each individual test in savepoint/rollback, and then set just the GUCs
> > needed to get the plan shape and execution code path I wanted to
> >
Thomas Munro writes:
> On Tue, Jul 9, 2019 at 2:19 AM Tom Lane wrote:
>> Given the purposes of this test, I think it'd be reasonable to force
>> both enable_hashjoin = on and enable_mergejoin = off at the very top
>> of the join_hash script, or the corresponding place in join.sql in
>> v11.
Michael Paquier writes:
> On Mon, Jul 08, 2019 at 03:21:41PM -0400, Tom Lane wrote:
>> Having said that, join_hash.sql in particular seems to have zero
>> value if it's not testing hash joins, so I think it'd be reasonable
>> for it to override a global enable_hashjoin = off setting. None of
>>
On Tue, Jul 9, 2019 at 2:19 AM Tom Lane wrote:
> Given the purposes of this test, I think it'd be reasonable to force
> both enable_hashjoin = on and enable_mergejoin = off at the very top
> of the join_hash script, or the corresponding place in join.sql in
> v11. Thomas, was there a specific
On Mon, Jul 08, 2019 at 03:21:41PM -0400, Tom Lane wrote:
> Having said that, join_hash.sql in particular seems to have zero
> value if it's not testing hash joins, so I think it'd be reasonable
> for it to override a global enable_hashjoin = off setting. None of
> the other regression test
Michael Paquier writes:
> Well, another thing I'd like to think about is if there is any point
> to keep regressplans.sh and the relevant options in postgres at this
> stage. From the top of the file one can read that:
The point of regressplans.sh is to see if anything goes seriously
wrong when
On Mon, Jul 8, 2019 at 5:53 PM Michael Paquier wrote:
> I have begun playing with regressplans.sh which enforces various
> combinations of "-f s|i|n|m|h" when running the regression tests, and
> I have noticed that -fh can cause the server to become stuck in the
> test join_hash.sql with this
On Mon, Jul 08, 2019 at 06:49:44PM +1200, Thomas Munro wrote:
> "simple" has 20k rows and "extremely_skewed" has 20k rows but the
> planner thinks it only has 2. So this going to take O(n^2) time and n
> is 20k. Not sure what to do about that. Maybe "join_hash" should be
> skipped for the -h (=
Michael Paquier writes:
> I have begun playing with regressplans.sh which enforces various
> combinations of "-f s|i|n|m|h" when running the regression tests, and
> I have noticed that -fh can cause the server to become stuck in the
> test join_hash.sql with this query (not sure which portion of
Hi all,
I have begun playing with regressplans.sh which enforces various
combinations of "-f s|i|n|m|h" when running the regression tests, and
I have noticed that -fh can cause the server to become stuck in the
test join_hash.sql with this query (not sure which portion of the SET
LOCAL parameters
22 matches
Mail list logo
