From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallel Seq Scan |
Date: | 2014-12-05 15:16:10 |
Message-ID: | 20141205151610.GP25679@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Amit,
* Amit Kapila (amit(dot)kapila16(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-12-05 15:17:50 | Re: [REVIEW] Re: Compression of full-page-writes |
Previous Message | Stephen Frost | 2014-12-05 15:13:40 | Re: Parallel Seq Scan |