Tweak new regression test case for better portability.

Buildfarm says we get different plans on 32-bit and 64-bit platforms,
probably because of MAXALIGN-related differences in memory-consumption
calculations.  Add some dummy WHERE clauses so that the planner estimates
different sizes for the three generate_series() relations; that should
stabilize the choice of join order.

src/test/regress/expected/pg_lsn.out

@@ -70,6 +70,7 @@ SELECT DISTINCT (i || '/' || j)::pg_lsn f
   FROM generate_series(1, 10) i,
        generate_series(1, 10) j,
        generate_series(1, 5) k
+  WHERE i <= 10 AND j > 0 AND j <= 10
   ORDER BY f;
                                 QUERY PLAN                                
 --------------------------------------------------------------------------
@@ -81,14 +82,17 @@ SELECT DISTINCT (i || '/' || j)::pg_lsn f
                ->  Function Scan on generate_series k
                ->  Materialize
                      ->  Nested Loop
-                           ->  Function Scan on generate_series i
                            ->  Function Scan on generate_series j
-(10 rows)
+                                 Filter: ((j > 0) AND (j <= 10))
+                           ->  Function Scan on generate_series i
+                                 Filter: (i <= 10)
+(12 rows)
 
 SELECT DISTINCT (i || '/' || j)::pg_lsn f
   FROM generate_series(1, 10) i,
        generate_series(1, 10) j,
        generate_series(1, 5) k
+  WHERE i <= 10 AND j > 0 AND j <= 10
   ORDER BY f;
    f   
 -------

src/test/regress/sql/pg_lsn.sql

@@ -30,10 +30,12 @@ SELECT DISTINCT (i || '/' || j)::pg_lsn f
   FROM generate_series(1, 10) i,
        generate_series(1, 10) j,
        generate_series(1, 5) k
+  WHERE i <= 10 AND j > 0 AND j <= 10
   ORDER BY f;
 
 SELECT DISTINCT (i || '/' || j)::pg_lsn f
   FROM generate_series(1, 10) i,
        generate_series(1, 10) j,
        generate_series(1, 5) k
+  WHERE i <= 10 AND j > 0 AND j <= 10
   ORDER BY f;