Hi Pavel,
Here are the explains you asked for:
explain analyze select string_agg(id::text,',') from things group by guid;
QUERY PLAN
---
Can you send a EXPLAIN result in both use cases?
Pavel
2013/8/19 Robert Sosinski
> At the moment, all guids are distinct, however before I zapped the
> duplicates, there were 280 duplicates.
>
> Currently, there are over 2 million distinct guids.
>
> -Robert
>
>
> On Mon, Aug 19, 2013 at 11:12
Hello
It is strange. I am trying to simulate it without success. On 1 M rows
where every id is 2 times duplicated
processing string_agg .. cca 30MB
processing array_agg cca 32MB
postgres=# create table foo(a int, b varchar);
CREATE TABLE
postgres=# insert into foo select i, md5(i::text) from
ge
At the moment, all guids are distinct, however before I zapped the
duplicates, there were 280 duplicates.
Currently, there are over 2 million distinct guids.
-Robert
On Mon, Aug 19, 2013 at 11:12 AM, Pavel Stehule wrote:
>
>
>
> 2013/8/19 Robert Sosinski
>
>> Hi Pavel,
>>
>> What kind of exam
2013/8/19 Robert Sosinski
> Hi Pavel,
>
> What kind of example do you need? I cant give you the actual data I have
> in the table, but I can give you an example query and the schema attached
> below. From there, I would just put in 2 million rows worth 1.2 Gigs of
> data. Average size of the t
Hi Pavel,
What kind of example do you need? I cant give you the actual data I have
in the table, but I can give you an example query and the schema attached
below. From there, I would just put in 2 million rows worth 1.2 Gigs of
data. Average size of the the extended columns (using the pg_colum
Hello
please, can you send some example or test?
Regards
Pavel Stehule
2013/8/19 Robert Sosinski
> When using array_agg on a large table, memory usage seems to spike up
> until Postgres crashes with the following error:
>
> 2013-08-17 18:41:02 UTC [2716]: [2] WARNING: terminating connection
## Robert Sosinski (rsosin...@ticketevolution.com):
> When using array_agg on a large table, memory usage seems to spike up until
> Postgres crashes with the following error:
This sounds like bug #7916.
http://www.postgresql.org/message-id/e1uceeu-0004hy...@wrigleys.postgresql.org
As noted in tha
When using array_agg on a large table, memory usage seems to spike up until
Postgres crashes with the following error:
2013-08-17 18:41:02 UTC [2716]: [2] WARNING: terminating connection because
of crash of another server process
2013-08-17 18:41:02 UTC [2716]: [3] DETAIL: The postmaster has comma
Thanx for the link.
I just think that it would be a good idea, instead of posting the links at this
list, to include a
dense but detailed summary of the situation in your machine, and give as much
data as possible.
In short, you might do a quantitative compilation of this thread, and present
it
FYI
http://freebsd.1045724.n5.nabble.com/Postgresql-related-memory-question-td5759467.html
Am 2012-11-07 10:28, schrieb Achilleas Mantzios:
On Τετ 07 Νοε 2012 09:42:47 Frank Broniewski wrote:
Hey, this is really cool. I directly tried the script and there's a line
from the output that caught
Vick,
fantastic script, thanx! FreeBSD sysctl system is awesome!
On Τρι 06 Νοε 2012 14:33:43 Vick Khera wrote:
On Mon, Nov 5, 2012 at 10:11 AM, Frank Broniewski wrote:
and this is after a few hours of running:
Mem: 91M Active, 17G Inact, 3983M Wired, 1526M Cache, 3283M Buf, 155M Free
Swap: 4
On Τετ 07 Νοε 2012 09:42:47 Frank Broniewski wrote:
> Hey, this is really cool. I directly tried the script and there's a line
> from the output that caught my eye:
>
> > mem_gap_vm: + 8812892160 ( 8404MB) [ 26%] Memory gap: UNKNOWN
>
> is this the shared buffers? I guess so, but I want to
Hey, this is really cool. I directly tried the script and there's a line
from the output that caught my eye:
> mem_gap_vm: + 8812892160 ( 8404MB) [ 26%] Memory gap: UNKNOWN
is this the shared buffers? I guess so, but I want to confirm my guess ...
Frank
Am 2012-11-07 09:26, schrieb Achil
Vick,
fantastic script, thanx! FreeBSD sysctl system is awesome!
On Τρι 06 Νοε 2012 14:33:43 Vick Khera wrote:
On Mon, Nov 5, 2012 at 10:11 AM, Frank Broniewski wrote:
and this is after a few hours of running:
Mem: 91M Active, 17G Inact, 3983M Wired, 1526M Cache, 3283M Buf, 155M Free
Swap: 4
On Mon, Nov 5, 2012 at 10:11 AM, Frank Broniewski wrote:
> and this is after a few hours of running:
>
> Mem: 91M Active, 17G Inact, 3983M Wired, 1526M Cache, 3283M Buf, 155M Free
> Swap: 4096M Total, 828K Used, 4095M Free
>
>
For comparison, here is the output of a 32GB FreeBSD 9.0/amd64 server,
Since the top reporting goes back to normal when postgresql is stopped ,
and since postgresql is special due to the use of IPC, i would be inclined
to think that the culprit here is the shared memory.
I don't know where maintenance_work_mem really lives (process normal address
space or IPC share
Hi,
I just add the different memory values together (minus the buffers).
Usually this sums up (+/-) to the installed memory size, at least on my
other machines. I found a thread similar to my problem here [1], but no
solution. I don't mind top showing false values, but if there's a larger
pro
How do you measure that smth is missing from top? What values do you add?
I am currently running 8.3 but we shouldn't be so far apart top-wise.
What is the reading under SIZE and RES in top for all postgresql processes?
Take note that shared mem should be recorded for each and every postmaster
run
Hi,
thank you for your feedback. I had a look at those commands and their
output, especially in conjunction with the SEGSZ value from icps -am
Here's an example output:
# ipcs -am
Shared Memory:
T ID KEY MODEOWNERGROUPCREATOR
CGROUP NATTCHSE
(scrap my previous internal email (hence fake) address this one is correct :
sorry for that)
You can stop pgsql, start it and then watch out for the increase in SEGSZ
values. I pretty much think they are in bytes.
I am pretty confident that this value depicts the shared_buffers size in bytes.
ipcs in FreeBSD is a little ... tricky.
ipcs -M
ipcs -m
ipcs -am
could be your friends
On Δευ 05 Νοε 2012 11:22:46 Frank Broniewski wrote:
> Hi,
>
> I am running a PostgreSQL server on FreeBSD. The system has 32GB memory.
> Usually I use top to examine the memory usage of the system. After a
Hi,
I am running a PostgreSQL server on FreeBSD. The system has 32GB memory.
Usually I use top to examine the memory usage of the system. After a
while, a part, approximately 5GB, vanish from top, so that the memory
rounds up to 27GB. After restarting PostgreSQL, I have all 32GB again
availa
Cc: PostgreSQL General
Sent: Thursday, November 3, 2011 10:30:27 AM
Subject: Re: [GENERAL] Memory Issue
On Thu, Nov 3, 2011 at 7:34 AM, Ioana Danes wrote:
> After another half an hour almost the entire swap is used and the system
> performs really bad 100 TPS or lower.
> It never ru
- Original Message -
From: Scott Marlowe
To: Ioana Danes
Cc: PostgreSQL General
Sent: Thursday, November 3, 2011 10:30:27 AM
Subject: Re: [GENERAL] Memory Issue
On Thu, Nov 3, 2011 at 7:34 AM, Ioana Danes wrote:
> After another half an hour almost the entire swap is used and
On Thu, Nov 3, 2011 at 7:34 AM, Ioana Danes wrote:
> Hello Everyone,
>
> I have a performance test running with 1200 clients performing this
> transaction every second:
>
>
> begin transaction
> select nextval('sequence1');
> select nextval('sequence2');
> insert into table1;
> insert into table2
Hello Everyone,
I have a performance test running with 1200 clients performing this transaction
every second:
begin transaction
select nextval('sequence1');
select nextval('sequence2');
insert into table1;
insert into table2;
commit;
Table1 and table2 have no foreign keys and no triggers. Ther
27 matches
Mail list logo
