Re: SerializeParamList vs machines with strict alignment - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: SerializeParamList vs machines with strict alignment
Date
Msg-id CAA4eK1JYfe-Sxi3RjjBTnf1y1d-TNK+9nt1-cLajBuaXnJM+8A@mail.gmail.com
Whole thread Raw
In response to Re: SerializeParamList vs machines with strict alignment  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SerializeParamList vs machines with strict alignment  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Oct 2, 2018 at 5:31 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
> > On Tue, Oct 2, 2018 at 9:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Apparently the only somewhat-modern architecture that is resolutely
> >> unaligned-unfriendly is MIPS.
>
> > It's been a few years now since I worked on that architecture, but
> > Sparc is somewhat-modern and resolutely unaligned-unfriendly.  It's
> > just that you can optionally install a trap handler that will do super
> > slow non-atomic misaligned access in software instead of blowing up
> > with SIGBUS.  With the Sun toolchain you did that explicitly by
> > building with -misalign (though it's possible that more recent
> > compilers might be doing that without being asked?).
>
> Interesting ... I suppose we'd have seen that on the Sparc critters,
> except that they weren't running with force_parallel_mode = regress
> like chipmunk is.
>
> Now I'm tempted to propose that Amit commit *just* the test case
> and not the fix, and wait a day to see which buildfarm critters fail.
>

Okay, I will take care of that.  Are you proposing to commit the test
only on HEAD or in back-branches as well?  Ideally committing on HEAD
would serve our purpose.
There is one difference in our tests which I would like to highlight:
fix_datum_serialization_v2:
+EXPLAIN (COSTS OFF) EXECUTE stmt_sel_domain(make_psafe_ad(1,2));
+                       QUERY PLAN
+--------------------------------------------------------
+ Gather
+   Workers Planned: 1
+   Single Copy: true
+   ->  Seq Scan on tarrdomain
+         Filter: ((c2)::integer[] = '{1,2}'::integer[])
+(5 rows)

fix_datum_serialization_v3
! EXPLAIN (COSTS OFF) EXECUTE pstmt('1', make_some_array(1,2));
!                             QUERY PLAN
! ------------------------------------------------------------------
!  Gather
!    Workers Planned: 3
!    ->  Parallel Seq Scan on foo
!          Filter: ((f1 = '1'::text) AND (f2 = '{1,2}'::integer[]))
! (4 rows)

I think if we do Analyze on the table after populating rows, it should
use just one worker and that should be sufficient to hit the case
being discussed.  I would like to change the test so that it uses just
one worker.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: speeding up planning with partitions
Next
From: Michael Paquier
Date:
Subject: Re: [FEATURE PATCH] pg_stat_statements with plans (v02)