pá 18. 9. 2020 v 6:35 odesílatel Yessica Brinkmann <
brinkmann.yess...@gmail.com> napsal:
> I already discovered the problem, it was only a counter initialization
> issue, it had nothing to do with memory contexts, that part was fine. Thank
> God I could already understand the problem and solve it
I already discovered the problem, it was only a counter initialization
issue, it had nothing to do with memory contexts, that part was fine. Thank
God I could already understand the problem and solve it.
Anyway thank you very much.
Best regards,
Yessica Brinkmann
El jue., 17 sept. 2020 a las 22:2
Thank you very much for the answers, and for the advice given. I will try
to put them into practice.
Best regards,
Yessica Brinkmann
El jue., 17 sept. 2020 a las 6:46, Yessica Brinkmann (<
brinkmann.yess...@gmail.com>) escribió:
>
>
> Good Morning. Thank you so much for the answers. Now I have
On Thu, Sep 17, 2020 at 10:06:07AM -0400, Tom Lane wrote:
> =?UTF-8?Q?=C3=98ystein_Kolsrud?= writes:
> > So my question is: When does a postgres process forked for a connection use
> > private memory instead of shared, and what can I do to avoid this?
>
> The only significant long-term consumpt
Dear All,
To further promote the use of PostgreSQL as a service, we need working
examples for common application users to understand what to do, and to
prepare data resources for them.
These users may use PowerBI, Excel, graphical packages and more specialist
applications such as ArcGIS.
Are ther
Ben
writes:
> You are right none of them is what I originally used to create them
> which should be
> `select * from utlog.stats_per_shift_filtered_b0206`, but they do look
> different,
This discrepancy could explain a lot:
> (stats_per_shift_filtered_u0206.wsft)::character varying AS
Hi Sievers, Krishna
You are right none of them is what I originally used to create them
which should be
`select * from utlog.stats_per_shift_filtered_b0206`, but they do look
different,
maybe the prev version is created before a pg update ? b0206 could be
20190206 or 20180206...
the output
On 2020-09-17 11:19:07 +0200, Øystein Kolsrud wrote:
> I have a product that uses PostgreSQL (v9.6) as database on Windows, and we
> often observe that the "shared working set" memory reported for the individual
> connection processes is quite high (around 200MB), but the "private working
> set" is
Ben writes:
> Dear List,
>
> Some further investigation.
>
> Creating a fresh View3 on View1 gives exactly the same result as
> View1.
>
> The View1 View2 are both years old in a production database, in use
> for quite some time. (The database is production duty but not hosted
> in server room wi
=?UTF-8?Q?=C3=98ystein_Kolsrud?= writes:
> So my question is: When does a postgres process forked for a connection use
> private memory instead of shared, and what can I do to avoid this?
The only significant long-term consumption of private memory is for
caches. There are catalog caches, which
>I haven't replaced the broken View2 yet. >Hope someone can point me to some
>>further investigation.
Did you look at the actual definition of view2. Like all RDBMS PG materializes
the Ddl as it existed at the time of creation and converts it into an in line
sql.
There is a possibility it ma
Dear List,
Some further investigation.
Creating a fresh View3 on View1 gives exactly the same result as View1.
The View1 View2 are both years old in a production database, in use for quite
some time. (The database is production duty but not hosted in server room with
UPS. It's like a edge PC i
Øystein Kolsrud schrieb am 17.09.2020 um 11:19:
All settings typically referred to (like "work_mem" and
"temp_buffers") are at default settings, and I have a very hard time
seeing how those settings could add up to memory in the magnitude of
200MB. The "max_connections" settings is quite high (>1
Good Morning. Thank you so much for the answers. Now I have to go to work, but when I come back I will be looking at the answers in detail, and I will answer. Unfortunately I have to work and study as well, so right now I can't see the answers in detail.Best regards,Yessica Brinkmann. Mens
I have a product that uses PostgreSQL (v9.6) as database on Windows, and we
often observe that the "shared working set" memory reported for the
individual connection processes is quite high (around 200MB), but the
"private working set" is relatively low (around 5 MB). I assume this is due
to the pr
15 matches
Mail list logo