Re: How the Planner in PGStrom differs from PostgreSQL?

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Mark Anns <aishwaryaanns(at)gmail(dot)com>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: How the Planner in PGStrom differs from PostgreSQL?
Date: 2016-11-17 15:28:38
Message-ID: CA+HiwqEodoqNe5P7OUR7u95gJGXAbSqa261Ag0oxh9rSeEpG9g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Nov 17, 2016 at 7:09 PM, Mark Anns <aishwaryaanns(at)gmail(dot)com> wrote:
> Can u explain this statement "check whether the scan qualifier can
> be executable on GPU device"
>
> What are the scan qualifiers?
>
> How to determine whether they are device executable or not?
>
> The cost estimates are entirely based on number of rows and type of scan.
> Then it will be same for both CPU and GPU. How the decision can be made for
> cheaper one comparing CPU and GPU estimates?

There is a parameter (call it a "factor" if you will) called
cpu_tuple_cost (section 19.7.2 Planner Cost Constants in the
PostgreSQL documentation; link at the bottom), which "sets the
planner's estimate of the cost of processing each row during a query"
as the description on that page says.

With that as the unit of cost of processing rows using the CPU and
considering any differences in the processing capabilities between CPU
and GPU, the optimizer code will cost the portion of plan that will be
processed by the GPU (typically a table scan or a join) as some
fraction of the cost of executing the same portion of the plan using
the traditional CPU processing.

(Kaigai-san will be better able to explain and correct if the above
rough sketch is not exactly accurate)

Thanks,
Amit

[1] https://www.postgresql.org/docs/9.6/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message kbrannen 2016-11-17 16:16:51 help with moving tablespace
Previous Message Adrian Klaver 2016-11-17 14:59:46 Re: pg_class (system) table increasing size.