3 replaced http://dba.stackexchange.com/ with https://dba.stackexchange.com/
source | link

Memory related settings

You've already addressed the key bottleneck for read heavy applications, that is, having sufficient RAM for caching. Just make sure you've set appropriately high values for shared_bufferes, work_mem, maintenance_work_mem, and effective_cache_size within your postgresql.conf file.

Actually, there's a litany of good info in this DBA.SE thread.this DBA.SE thread.

Also, here's a link to the Postgres Docs about these settings, amongst others.

Processor choice

As for choice of processors, it is important to keep in mind that Postgres is not capable of using more than one CPU per database process. If there will be many concurrently connected users, a multi-core CPU can spread out the user queries amongst the cores, but cannot parallelize on a per-query basis. Effectively, you will only get to truly leverage a benefit from multiple cores when there are multiple connected users.

I guess, to answer succinctly, that if you have only one (or a small number) of users, favor faster cores, whereas if you'll have many concurrent users, you could benefit from a little of both.

Refer to this DBA.SE threadthis DBA.SE thread which covers some of this info.

If you are going to have many concurrently users, I would suggest you also look in to connection pooling.

Memory related settings

You've already addressed the key bottleneck for read heavy applications, that is, having sufficient RAM for caching. Just make sure you've set appropriately high values for shared_bufferes, work_mem, maintenance_work_mem, and effective_cache_size within your postgresql.conf file.

Actually, there's a litany of good info in this DBA.SE thread.

Also, here's a link to the Postgres Docs about these settings, amongst others.

Processor choice

As for choice of processors, it is important to keep in mind that Postgres is not capable of using more than one CPU per database process. If there will be many concurrently connected users, a multi-core CPU can spread out the user queries amongst the cores, but cannot parallelize on a per-query basis. Effectively, you will only get to truly leverage a benefit from multiple cores when there are multiple connected users.

I guess, to answer succinctly, that if you have only one (or a small number) of users, favor faster cores, whereas if you'll have many concurrent users, you could benefit from a little of both.

Refer to this DBA.SE thread which covers some of this info.

If you are going to have many concurrently users, I would suggest you also look in to connection pooling.

Memory related settings

You've already addressed the key bottleneck for read heavy applications, that is, having sufficient RAM for caching. Just make sure you've set appropriately high values for shared_bufferes, work_mem, maintenance_work_mem, and effective_cache_size within your postgresql.conf file.

Actually, there's a litany of good info in this DBA.SE thread.

Also, here's a link to the Postgres Docs about these settings, amongst others.

Processor choice

As for choice of processors, it is important to keep in mind that Postgres is not capable of using more than one CPU per database process. If there will be many concurrently connected users, a multi-core CPU can spread out the user queries amongst the cores, but cannot parallelize on a per-query basis. Effectively, you will only get to truly leverage a benefit from multiple cores when there are multiple connected users.

I guess, to answer succinctly, that if you have only one (or a small number) of users, favor faster cores, whereas if you'll have many concurrent users, you could benefit from a little of both.

Refer to this DBA.SE thread which covers some of this info.

If you are going to have many concurrently users, I would suggest you also look in to connection pooling.

2 added 197 characters in body
source | link

Memory related settings

You've already addressed the key bottleneck for read heavy applications, that is, having sufficient RAM for caching. Just make sure you've set appropriately high values for shared_bufferes, work_mem, maintenance_work_mem, and effective_cache_size within your postgresql.conf file.

Actually, there's a litany of good info in this DBA.SE thread.

Also, here's a link to the Postgres Docs about these settings, amongst others.

Processor choice

As for choice of processors, it is important to keep in mind that Postgres is not capable of using more than one CPU per database process. If there will be many concurrently connected users, a multi-core CPU can spread out the user queries amongst the cores, but cannot parallelize on a per-query basis. Effectively, you will only get to truly leverage a benefit from multiple cores when there are multiple connected users.

I guess, to answer succinctly, that if you have only one (or a small number) of users, favor faster cores, whereas if you'll have many concurrent users, you could benefit from a little of both.

Refer to this DBA.SE thread which covers some of this info.

If you are going to have many concurrently users, I would suggest you also look in to connection pooling.

Memory related settings

You've already addressed the key bottleneck for read heavy applications, that is, having sufficient RAM for caching. Just make sure you've set appropriately high values for shared_bufferes, work_mem, maintenance_work_mem, and effective_cache_size within your postgresql.conf file.

Actually, there's a litany of good info in this DBA.SE thread.

Also, here's a link to the Postgres Docs about these settings, amongst others.

Processor choice

As for choice of processors, it is important to keep in mind that Postgres is not capable of using more than one CPU per database process. If there will be many concurrently connected users, a multi-core CPU can spread out the user queries amongst the cores, but cannot parallelize on a per-query basis. Effectively, you will only get to truly leverage a benefit from multiple cores when there are multiple connected users.

Refer to this DBA.SE thread which covers some of this info.

If you are going to have many concurrently users, I would suggest you also look in to connection pooling.

Memory related settings

You've already addressed the key bottleneck for read heavy applications, that is, having sufficient RAM for caching. Just make sure you've set appropriately high values for shared_bufferes, work_mem, maintenance_work_mem, and effective_cache_size within your postgresql.conf file.

Actually, there's a litany of good info in this DBA.SE thread.

Also, here's a link to the Postgres Docs about these settings, amongst others.

Processor choice

As for choice of processors, it is important to keep in mind that Postgres is not capable of using more than one CPU per database process. If there will be many concurrently connected users, a multi-core CPU can spread out the user queries amongst the cores, but cannot parallelize on a per-query basis. Effectively, you will only get to truly leverage a benefit from multiple cores when there are multiple connected users.

I guess, to answer succinctly, that if you have only one (or a small number) of users, favor faster cores, whereas if you'll have many concurrent users, you could benefit from a little of both.

Refer to this DBA.SE thread which covers some of this info.

If you are going to have many concurrently users, I would suggest you also look in to connection pooling.

1
source | link

Memory related settings

You've already addressed the key bottleneck for read heavy applications, that is, having sufficient RAM for caching. Just make sure you've set appropriately high values for shared_bufferes, work_mem, maintenance_work_mem, and effective_cache_size within your postgresql.conf file.

Actually, there's a litany of good info in this DBA.SE thread.

Also, here's a link to the Postgres Docs about these settings, amongst others.

Processor choice

As for choice of processors, it is important to keep in mind that Postgres is not capable of using more than one CPU per database process. If there will be many concurrently connected users, a multi-core CPU can spread out the user queries amongst the cores, but cannot parallelize on a per-query basis. Effectively, you will only get to truly leverage a benefit from multiple cores when there are multiple connected users.

Refer to this DBA.SE thread which covers some of this info.

If you are going to have many concurrently users, I would suggest you also look in to connection pooling.