Re: [PERFORM] https://stackoverflow.com/questions/28844170/how-to-limit-the-memory-that-is-available-for-postgressql-server

On 09/18/2017 10:44 PM, George Neuner wrote: > On Tue, 19 Sep 2017 00:49:14 +, wrote: > >> For an academic experiment I need to *restrict the total amount of memory >> that is available for a pgSQL server* to compute a given set of queries. >> >> I know that I

Re: [PERFORM] Pageinspect bt_metap help

Peter Geoghegan writes: > On Mon, Sep 18, 2017 at 7:31 AM, Neto pr wrote: >> In my example, the values of fast_root, fast_root are equal to root, level, >> I believe that due to the newly created index and no delete operations >> occurred in the table. > Fast

Re: [PERFORM] https://stackoverflow.com/questions/28844170/how-to-limit-the-memory-that-is-available-for-postgressql-server

On Tue, 19 Sep 2017 00:49:14 +, wrote: For an academic experiment I need to *restrict the total amount of memory that is available for a pgSQL server* to compute a given set of queries. I know that I can do this through postgressql.conffile, where I can adjust

Re: [PERFORM] Pageinspect bt_metap help

On Mon, Sep 18, 2017 at 7:31 AM, Neto pr wrote: > In my example, the values of fast_root, fast_root are equal to root, level, > I believe that due to the newly created index and no delete operations > occurred in the table. Fast root and true root will probably never be

[PERFORM] https://stackoverflow.com/questions/28844170/how-to-limit-the-memory-that-is-available-for-postgressql-server

Hi experts, For an academic experiment I need to *restrict the total amount of memory that is available for a pgSQL server* to compute a given set of queries. I know that I can do this through postgressql.conffile, where I can adjust some parameters related with Resource Management. The problem

Re: [PERFORM] Pageinspect bt_metap help

Very interesting information. See if I'm right, so for performance purposes, would it be better to consider the columns: fast_root and fast_level instead of the root and level columns? I have read that even deleting records the B-tree tree is not rebuilt, so it does not cause overhead in dbms,

Re: [PERFORM] max partitions behind a view?

Rick Otten writes: > The challenge is that because of an exponential rate of data growth, I > might have to significantly increase the number of partitions I'm working > with - to several hundred at a minimum and potentially more than 1000... > This leads me to the

[PERFORM] max partitions behind a view?

I use materialized views to cache results from a foreign data wrapper to a high latency, fairly large (cloud) Hadoop instance. In order to boost refresh times I split the FDW and materialized views up into partitions. Note: I can't use pg_partman or native partitioning because those don't