Tuning advices for GPU computation wanted

[eugeneYWang]

a question about tuning. For original CPU-based Postgres (9+), parallel connections cost the same work_mem and resources as normal connections, and maximum parallel workers is suggested to be set as the number of CPU cores. So we know how to calculate work_mem and nums of total connections and parallel workers.

When it comes to GPU Postgres, I guess those rules might be different. As the founder of this GPU-based extension, do you have any tuning advice or any instruction about configurations in postgresql.conf ?

Just so you know, my case is a postgres 12 used to do heavy geospatial-analytics queries. Currently our CPU-based Postgres VM with 28GB RAM has given 103MB for work_mem and 100 total connections.

[eugeneYWang]

Looking forward to hearing from you, @kaigai

[kaigai]

Once a workload is moved to GPU, it is enought parallelized on the device side.
E.g, PG-Strom runs thousands threads to check geospatial-clauses in WHERE/JOIN.

On the other hand, we don't recommend to use many PostgreSQL backend concurrently
bacause they try to consume GPU's resource at lease ~300MB for each backend process
and GPU is not a time sharing system, therefore, many concurrent backends are harmfull
and makes no sense.

Sorry for my late response, due to the funneral of my father last week.

Best regards,

[eugeneYWang]

Thank you for answering my question thoughtfully!

I am sorry to hear your loss of your father.

御愁傷様です

Please take care.

[eugeneYWang]

we don't recommend to use many PostgreSQL backend concurrently
bacause they try to consume GPU's resource at lease ~300MB for each backend process

Do you have any specific recommendation about concurrent requests ? like how many is too much / too little. Or how much is appropriate?

Currently, I set this concurrent number by the number of CPU cores. Would this be recommended on GPU Postgres? Too much or too less?

[eugeneYWang]

forgot to mention you, @kaigai

[kaigai]

Number of CPUs is not related to the resource consumption of PG-Strom.
Even if a single PostgreSQL backend is working, it kicks enough number of threads on GPU; usually more than 10k threads.
As long as i/o performance is sufficient, we like to recommend 2-3 concurrent backend and max_parallel_workers < 4 for each.

If you focus on PostGIS workloads, several new functions in v3.0 might be helpful.
http://heterodb.github.io/pg-strom/ref_devfuncs/#postgis-functions