Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j18E9-0007fy-2Y for pgsql-performance@arkaria.postgresql.org; Mon, 10 Feb 2020 12:31:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j18E7-0005OJ-AC for pgsql-performance@arkaria.postgresql.org; Mon, 10 Feb 2020 12:31:47 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j18E7-0005OB-0Y for pgsql-performance@lists.postgresql.org; Mon, 10 Feb 2020 12:31:47 +0000 Received: from mail112245.hm1479.locaweb.com.br ([189.126.112.245]) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1j18E1-0002Q4-0D for pgsql-performance@lists.postgresql.org; Mon, 10 Feb 2020 12:31:45 +0000 Received: from mcbain0002.correio.biz (189.126.112.13) by mail4970.hm1479.locaweb.com.br id h856gm16a4cp for ; Mon, 10 Feb 2020 09:31:01 -0300 (envelope-from ) Received: from proxy.email-ssl.com.br (bartf0025.email.locaweb.com.br [10.31.120.57]) by mcbain0002.correio.biz (Postfix) with ESMTP id 73FA180A04F; Mon, 10 Feb 2020 09:31:05 -0300 (-03) x-locaweb-id: qyHzKK_R8aWhjwoIerpCUhsi5PfCUymhK53qXIAegdcRogeYX3-XTadcSpgGGxitWQf3rKGbFuqvLmn5XdJ_XeDnSC7FYZn7HbLXpGF-9IgCFmgQGgrxCDEo15F9LB440m9K1Ks7WpF91ZBvw81jzMVxt2EKEGqqIzIkg6dcUj-wDGpfxhZYSv7g2tr9fc_TjkWl-e-E5Y47eweVIhFOCE0ElwFx-eZqcVXntQdvJEY= NmM3NTY5NzM3MjZmNjI2NTcyNzQ2ZjQwNzM2OTczNjM2ZjYyNzI2MTJlNjM2ZjZkMmU2Mjcy x-locaweb-id: qyHzKK_R8aWhjwoIerpCUhsi5PfCUymhK53qXIAegdcRogeYX3-XTadcSpgGGxitWQf3rKGbFuqvLmn5XdJ_XeDnSC7FYZn7HbLXpGF-9IgCFmgQGgrxCDEo15F9LB440m9K1Ks7WpF91ZBvw81jzMVxt2EKEGqqIzIkg6dcUj-wDGpfxhZYSv7g2tr9fc_TjkWl-e-E5Y47eweVIhFOCE0ElwFx-eZqcVXntQdvJEY= NmM3NTY5NzM3MjZmNjI2NTcyNzQ2ZjQwNzM2OTczNjM2ZjYyNzI2MTJlNjM2ZjZkMmU2Mjcy X-LocaWeb-COR: locaweb_2009_x-mail X-AuthUser: luisroberto@siscobra.com.br Received: from [192.168.0.21] (unknown [189.45.198.123]) (Authenticated sender: luisroberto@siscobra.com.br) by proxy.email-ssl.com.br (Postfix) with ESMTPSA id 8195CC1053; Mon, 10 Feb 2020 09:31:32 -0300 (-03) Cc: pgsql-performance@lists.postgresql.org Subject: Re: Fwd: TOAST table performance problem To: ayisan1096@gmail.com References: <9CE9EAEF-4DD1-4FCF-9B22-7609CBA83021@visena.com> From: =?UTF-8?Q?Lu=c3=ads_Roberto_Weck?= Message-ID: Date: Mon, 10 Feb 2020 09:31:30 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1588E47E40891E2E1FAD0E85" Content-Language: pt-BR List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------1588E47E40891E2E1FAD0E85 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit > ---------- Forwarded message --------- > Gönderen: *Asya Nevra Buyuksoy* > > Date: 10 Şub 2020 Pzt, 10:51 > Subject: Re: TOAST table performance problem > To: Andreas Joseph Krogh > > > > I copied my data to the CSV file, yes it is very fast. However, this > does not solve my problem. > After deserializing the on the front side, I want to visualize my data > on the web page effectively. > When I select my data one by one with a limit clause, the query > executes 200 ms. For example, If I create a function that takes data > with a loop, the execution time will be 200 ms*1000=200 sec. > > Andreas Joseph Krogh >, > 7 Şub 2020 Cum, 18:15 tarihinde şunu yazdı: > > Try \o in psql, to redirect the output to file, and > prevent it from processing the json (ie. format it) > > Den 7. februar 2020 15:59:05 CET, skrev Asya Nevra Buyuksoy > >: > > I try it, but there is no enhancement. > I read this link is about TOAST and also its sub_links; > https://blog.gojekengineering.com/a-toast-from-postgresql-83b83d0d0683 > > When I execute this query, except JSON data like; > SELECT paramuser_id, paramperson_id, paramisdeleted, > paramactiontime >   FROM zamazin; > It takes 94 ms. :) > > > Andreas Joseph Krogh >, 7 Şub 2020 Cum, 17:42 tarihinde > şunu yazdı: > > På fredag 07. februar 2020 kl. 15:35:04, skrev Asya Nevra > Buyuksoy >: > > I use pgadmin3. > > Try "psql", it has the lowest overhead (I think). pgAdmin > might use time presenting the results etc. which is easy > to overlook. > -- > Andreas Joseph Krogh > > > -- > Sendt fra min Android-enhet med K-9 e-post. Unnskyld min > kortfattethet. > What Andreas is trying to say is that it's not PostgreSQL that is slow to read the JSON, but your client app that is slow to parse it. --------------1588E47E40891E2E1FAD0E85 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
---------- Forwarded message ---------
Gönderen: Asya Nevra Buyuksoy <ayisan1096@gmail.com>
Date: 10 Şub 2020 Pzt, 10:51
Subject: Re: TOAST table performance problem
To: Andreas Joseph Krogh <andreas@visena.com>


I copied my data to the CSV file, yes it is very fast. However, this does not solve my problem.
After deserializing the on the front side, I want to visualize my data on the web page effectively.   
When I select my data one by one with a limit clause, the query executes 200 ms. For example, If I create a function that takes data with a loop, the execution time will be 200 ms*1000=200 sec.
 

Andreas Joseph Krogh <andreas@visena.com>, 7 Şub 2020 Cum, 18:15 tarihinde şunu yazdı:
Try \o <filename> in psql, to redirect the output to file, and prevent it from processing the json (ie. format it)

Den 7. februar 2020 15:59:05 CET, skrev Asya Nevra Buyuksoy <ayisan1096@gmail.com>:
I try it, but there is no enhancement.  
I read this link is about TOAST and also its sub_links;
When I execute this query, except JSON data like;
SELECT paramuser_id, paramperson_id, paramisdeleted, paramactiontime
  FROM zamazin;
It takes 94 ms. :)


Andreas Joseph Krogh <andreas@visena.com>, 7 Şub 2020 Cum, 17:42 tarihinde şunu yazdı:
På fredag 07. februar 2020 kl. 15:35:04, skrev Asya Nevra Buyuksoy <ayisan1096@gmail.com>:
I use pgadmin3.
 
Try "psql", it has the lowest overhead (I think). pgAdmin might use time presenting the results etc. which is easy to overlook.
 
--
Andreas Joseph Krogh

--
Sendt fra min Android-enhet med K-9 e-post. Unnskyld min kortfattethet.

What Andreas is trying to say is that it's not PostgreSQL that is slow to read the JSON, but your client app that is slow to parse it.
--------------1588E47E40891E2E1FAD0E85--