You now that Postgres don’t have any shared_pool as Oracle, and the session
information ( execution plan, etc..) are only available for the current
session. Therefore I also highly recommend to us a connection poll as Laurent
wrote, in order to have higher chance that some stuff is already
Daulat Ram wrote:
> We have migrated our database from Oracle 12c to Postgres 11. I need your
> suggestions ,
> we have sessions limit in Oracle = 3024 . Do we need to set the same
> connection limit
> in Postgres as well. How we can decide the max_connections limit for postgres.
> Are there
Hi
I didn't see my following response got posted on the mailing list so not
sure if it is duplicate.
Sorry for late reply.
The initial values before upgrade for seq_page_cost=1, random_page_cost=4
and after upgrading when we started to see the issues as we were seeing
"Seq Scan" we change them
From: Daulat Ram [mailto:daulat@exponential.com]
Sent: Wednesday, June 26, 2019 3:14 AM
To: pgsql-performance@lists.postgresql.org
Subject: Max_connections limit
Hello team,
We have migrated our database from Oracle 12c to Postgres 11. I need your
suggestions , we have sessions limit in
On Wed, Jun 26, 2019 at 5:16 AM Hervé Schweitzer (HER) <
herve.schweit...@dbi-services.com> wrote:
> You now that Postgres don’t have any shared_pool as Oracle, and the
> session information ( execution plan, etc..) are only available for the
> current session. Therefore I also highly recommend
Alvaro Herrera writes:
> On 2019-Jun-26, Hugh Ranalli wrote:
>> From my research in preparing for the upgrade, I understood transparent
>> huge pages were a good thing, and should be enabled. Is this not correct?
> It is not.
Yeah ... they would be a good thing perhaps if the quality of the
On 2019-Jun-26, Hugh Ranalli wrote:
> From my research in preparing for the upgrade, I understood transparent
> huge pages were a good thing, and should be enabled. Is this not correct?
It is not.
> Wouldn't the plan be the same at both
> the start of the week (when the problematic table is
On Wed, 26 Jun 2019 at 14:52, Peter Geoghegan wrote:
> Can you show us the definition of the table, including its indexes?
> Can you describe the data and distribution of values within the
> columns, particularly where they're indexed?
>
I'm sorry, but I'm not sure what you mean by the
On Wed, Jun 26, 2019 at 12:02 PM Hugh Ranalli wrote:
> I'm sorry, but I'm not sure what you mean by the "distribution of values
> within the columns." Can you clarify or provide an link to an example?
I would mostly just like to see the schema of the table in question,
including indexes, and a
On Tue, Jun 25, 2019 at 8:49 AM Hugh Ranalli wrote:
> What we continued to notice was a milder but still definite trend of
> increased query times, during the course of each week, from the mid to high
> 200 ms, to the high 300 ms to low 400 ms. Some years ago, someone had noticed
> that as the
On Tue, 25 Jun 2019 at 12:23, Justin Pryzby wrote:
> What kernel? Version? OS?
>
Ubuntu 18.04; current kernel is 4.15.0-51-generic4
If Linux, I wonder if transparent hugepages or KSM are enabled ? It seems
> possible that truncating the table is clearing enough RAM to mitigate the
> issue,
On Tue, 25 Jun 2019 at 11:55, Benjamin Scherrey
wrote:
> Have you done a VACUUM ANALYZE FULL on your database? This needs to be
> done periodically to inform the server of the statistics of how the data
> and relations are distributed across the database. Without this bad
> assumptions by the
On Tue, Jun 25, 2019 at 10:48:01AM +, Steven Winfield wrote:
> > ts=# explain SELECT * FROM eric_enodeb_cell_metrics WHERE start_time
> > BETWEEN '2019-01-01 04:00' AND '2019-01-01 05:00' OR start_time BETWEEN
> > '2019-01-02 04:00' AND '2019-01-02 05:00'
>
> Maybe it's because of the
On Tue, 25 Jun 2019 at 05:31, Justin Pryzby wrote:
> ts=# explain SELECT * FROM eric_enodeb_cell_metrics WHERE start_time BETWEEN
> '2019-01-01 04:00' AND '2019-01-01 05:00' OR start_time BETWEEN '2019-01-02
> 04:00' AND '2019-01-02 05:00';
> Append (cost=36.04..39668.56 rows=12817
On Wed, Jun 26, 2019 at 03:00:43PM -0400, Hugh Ranalli wrote:
> Pausing the admin queries isn't an option in our environment, especially as
> the issue reveals itself over the course of days, not minutes or hours.
Perhaps you can pause it for a short while at EOW and see if there's a dramatic
15 matches
Mail list logo
