Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Parallel Seq Scan
Date
Msg-id 20141205151610.GP25679@tamriel.snowman.net
Whole thread Raw
In response to Parallel Seq Scan  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Parallel Seq Scan  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Amit,

* Amit Kapila (amit.kapila16@gmail.com) wrote:
> postgres=# explain select c1 from t1;
>                       QUERY PLAN
> ------------------------------------------------------
>  Seq Scan on t1  (cost=0.00..101.00 rows=100 width=4)
> (1 row)
>
>
> postgres=# set parallel_seqscan_degree=4;
> SET
> postgres=# explain select c1 from t1;
>                           QUERY PLAN
> --------------------------------------------------------------
>  Parallel Seq Scan on t1  (cost=0.00..25.25 rows=100 width=4)
>    Number of Workers: 4
>    Number of Blocks Per Workers: 25
> (3 rows)

This is all great and interesting, but I feel like folks might be
waiting to see just what kind of performance results come from this (and
what kind of hardware is needed to see gains..).  There's likely to be
situations where this change is an improvement while also being cases
where it makes things worse.

One really interesting case would be parallel seq scans which are
executing against foreign tables/FDWs..
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Parallel Seq Scan
Next
From: Andres Freund
Date:
Subject: Re: [REVIEW] Re: Compression of full-page-writes