pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedTOAST table performance problem
15+ messages / 5 participants
[nested] [flat]
* TOAST table performance problem
@ 2020-02-07 13:07 Asya Nevra Buyuksoy <ayisan1096@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: Asya Nevra Buyuksoy @ 2020-02-07 13:07 UTC (permalink / raw)
To: pgsql-performance@lists.postgresql.org
Hello everybody,
I have trouble with my table that has four columns which their data types
are text, JSON, boolean and timestamp.
Also, I have 1K rows, but my JSON column size approximately 110KB and maybe
over it.
When I select all the data from my table, it takes 600 seconds.
But I explain my query;
*Seq Scan on zamazin (cost=0.00..21.77 rows=1077 width=49) (actual
time=0.004..0.112 rows=1077 loops=1)*
*Planning time: 0.013 ms*
*Execution time: 0.194 ms*
When I investigated why these execution times are so different, I find a
new storage logic like TOAST.
I overlook some details on TOAST logic and increased some config like
shared_buffers, work_mem, maintenance_work_mem, max_file_per_process.
But there was no performance improvement on my query.
I do not understand why it happens. My table size is 168 MB, but my TOAST
table size that is related to that table, is 123 MB.
*My environment is;*
PostgreSQL 9.4.1
Windows Server 2012 R2
16 GB RAM
100 GB HardDisk (Not SSD)
My database size 20 GB.
*My server configuration ;*
Shared_buffers: 8GB
( If I understand correctly, PostgreSQL says, For 9.4 The useful range for
shared_buffers on Windows systems is generally from 64MB to 512MB. Link:
https://www.postgresql.org/docs/9.4/runtime-config-resource.html )
work_mem : 512 MB
maintenance_work_mem: 1GB
max_file_per_process: 10000
effective_cache_size: 8GB
How I can achieve good performance?
Regards,
Mustafa BÜYÜKSOY
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: TOAST table performance problem
@ 2020-02-07 13:23 Asya Nevra Buyuksoy <ayisan1096@gmail.com>
parent: Asya Nevra Buyuksoy <ayisan1096@gmail.com>
0 siblings, 2 replies; 15+ messages in thread
From: Asya Nevra Buyuksoy @ 2020-02-07 13:23 UTC (permalink / raw)
To: Andreas Joseph Krogh <andreas@visena.com>; +Cc: pgsql-performance@lists.postgresql.org
Sorry for the misunderstanding.
I have a table like;
CREATE TABLE zamazin
(
paramuser_id text,
paramperson_id integer,
paramdata json,
paramisdeleted boolean,
paramactiontime timestamp without time zone
)
paramdata row size is 110KB and over.
When I execute this query like;
*select * from zamazin*
it takes *600 seconds*.
But when analyze the query ;
*"Seq Scan on public.zamazin (cost=0.00..21.77 rows=1077 width=49) (actual
time=0.008..0.151 rows=1077 loops=1)"" Output: paramuser_id,
paramperson_id, paramdata, paramisdeleted, paramactiontime"" Buffers:
shared hit=11""Planning time: 0.032 ms""Execution time: 0.236 ms"*
Why the query takes a long time, I do not understand. I assume that this
relates to the TOAST structure.
png.png
(11K)
<https://mail.google.com/mail/u/0?ui=2&ik=887fea0f99&attid=0.1&permmsgid=msg-a:r373414364...;
Andreas Joseph Krogh <andreas@visena.com>, 7 Şub 2020 Cum, 16:12 tarihinde
şunu yazdı:
> På fredag 07. februar 2020 kl. 14:07:28, skrev Asya Nevra Buyuksoy <
> ayisan1096@gmail.com>:
>
> Hello everybody,
>
> [...]
>
> How I can achieve good performance?
>
>
> Nobody here understands anything unless you show the exact query and
> schema...
>
> And of course you'll be encurraged to upgrade to latest version (12.1) as
> 9.4.1 is now 5 years old..
>
> --
> Andreas Joseph Krogh
>
Attachments:
[image/png] png.png (10.9K, ../../CADA48rE2DNh__WfU8v=CVL4wNypPXqrm_ikRDZiuahERoDCnbA@mail.gmail.com/3-png.png)
download | view image
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: TOAST table performance problem
@ 2020-02-07 13:34 Asya Nevra Buyuksoy <ayisan1096@gmail.com>
parent: Asya Nevra Buyuksoy <ayisan1096@gmail.com>
1 sibling, 0 replies; 15+ messages in thread
From: Asya Nevra Buyuksoy @ 2020-02-07 13:34 UTC (permalink / raw)
To: Andreas Joseph Krogh <andreas@visena.com>; +Cc: pgsql-performance@lists.postgresql.org
>
> Andreas Joseph Krogh <andreas@visena.com>, 7 Şub 2020 Cum, 16:12
> tarihinde şunu yazdı:
>
>> På fredag 07. februar 2020 kl. 14:07:28, skrev Asya Nevra Buyuksoy <
>> ayisan1096@gmail.com>:
>>
>>
>>
>> *[...]*
>>
>> *And of course you'll be encurraged to upgrade to latest version (12.1)
>> as 9.4.1 is now 5 years old..*
>> You are right but for now I have to use this version :)
>>
> --
>> Andreas Joseph Krogh
>>
>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: TOAST table performance problem
@ 2020-02-07 13:41 Andreas Joseph Krogh <andreas@visena.com>
parent: Asya Nevra Buyuksoy <ayisan1096@gmail.com>
1 sibling, 1 reply; 15+ messages in thread
From: Andreas Joseph Krogh @ 2020-02-07 13:41 UTC (permalink / raw)
To: pgsql-performance@lists.postgresql.org
På fredag 07. februar 2020 kl. 14:23:35, skrev Asya Nevra Buyuksoy <
ayisan1096@gmail.com <mailto:ayisan1096@gmail.com>>:
Sorry for the misunderstanding.
I have a table like;
CREATE TABLE zamazin
(
paramuser_id text,
paramperson_id integer,
paramdata json,
paramisdeleted boolean,
paramactiontime timestamp without time zone
)
paramdata row size is 110KB and over.
When I execute this query like;
select * from zamazin
it takes 600 seconds.
But when analyze the query ;
"Seq Scan on public.zamazin (cost=0.00..21.77 rows=1077 width=49) (actual
time=0.008..0.151 rows=1077 loops=1)"
" Output: paramuser_id, paramperson_id, paramdata, paramisdeleted,
paramactiontime"
" Buffers: shared hit=11"
"Planning time: 0.032 ms"
"Execution time: 0.236 ms"
Why the query takes a long time, I do not understand. I assume that this
relates to the TOAST structure.
My guess is the time is spent in the client retrieving the data, not in the DB
itself. Are you on a slow network?
--
Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andreas@visena.com <mailto:andreas@visena.com>
www.visena.com <https://www.visena.com;
<https://www.visena.com;
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: TOAST table performance problem
@ 2020-02-07 13:52 MichaelDBA <MichaelDBA@sqlexec.com>
parent: Andreas Joseph Krogh <andreas@visena.com>
0 siblings, 1 reply; 15+ messages in thread
From: MichaelDBA @ 2020-02-07 13:52 UTC (permalink / raw)
To: Andreas Joseph Krogh <andreas@visena.com>; +Cc: pgsql-performance@lists.postgresql.org
Yes, I would concur that this planning time and execution time do not
take into account the network time sending the data back to the client,
especially since your are sending back the entire contents of the table.
Regards,
Michael Vitale
Andreas Joseph Krogh wrote on 2/7/2020 8:41 AM:
> På fredag 07. februar 2020 kl. 14:23:35, skrev Asya Nevra Buyuksoy
> <ayisan1096@gmail.com <mailto:ayisan1096@gmail.com>>:
>
> Sorry for the misunderstanding.
> I have a table like;
> CREATE TABLE zamazin
> (
> paramuser_id text,
> paramperson_id integer,
> paramdata json,
> paramisdeleted boolean,
> paramactiontime timestamp without time zone
> )
> paramdata row size is 110KB and over.
> When I execute this query like;
> *select * from zamazin*
> it takes *600 seconds*.
> But when analyze the query ;
> *"Seq Scan on public.zamazin (cost=0.00..21.77 rows=1077
> width=49) (actual time=0.008..0.151 rows=1077 loops=1)"
> " Output: paramuser_id, paramperson_id, paramdata,
> paramisdeleted, paramactiontime"
> " Buffers: shared hit=11"
> "Planning time: 0.032 ms"
> "Execution time: 0.236 ms"*
> Why the query takes a long time, I do not understand. I
> assume that this relates to the TOAST structure.
>
> My guess is the time is spent in the /client/ retrieving the data, not
> in the DB itself. Are you on a slow network?
> --
> *Andreas Joseph Krogh*
> CTO / Partner - Visena AS
> Mobile: +47 909 56 963
> andreas@visena.com <mailto:andreas@visena.com>
> www.visena.com <https://www.visena.com;
> <https://www.visena.com;
Attachments:
[image/png] image.png (1.3K, ../../d2c78831-964e-4233-ac39-74a856bed78e@sqlexec.com/3-image.png)
download | view image
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: TOAST table performance problem
@ 2020-02-07 14:16 Asya Nevra Buyuksoy <ayisan1096@gmail.com>
parent: MichaelDBA <MichaelDBA@sqlexec.com>
0 siblings, 1 reply; 15+ messages in thread
From: Asya Nevra Buyuksoy @ 2020-02-07 14:16 UTC (permalink / raw)
To: MichaelDBA <MichaelDBA@sqlexec.com>; +Cc: Andreas Joseph Krogh <andreas@visena.com>; pgsql-performance@lists.postgresql.org
>
>
> Andreas Joseph Krogh wrote on 2/7/2020 8:41 AM:
>
> På fredag 07. februar 2020 kl. 14:23:35, skrev Asya Nevra Buyuksoy <
> ayisan1096@gmail.com>:
>
>
> My guess is the time is spent in the *client* retrieving the data, not in
> the DB itself. Are you on a slow network?
>
> It works in my local area and speed is 1 Gbps. When I use
another local computer that has SSD disk the query execution time reduced
to 12 seconds. But this query has to execute my local computer.
Attachments:
[image/png] image.png (1.3K, ../../CADA48rEzqEWoJhYaTb1PU6C9=Qr8PB-SAUxA=9_vuJa5wv=ZiA@mail.gmail.com/3-image.png)
download | view image
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: TOAST table performance problem
@ 2020-02-07 14:19 Andreas Joseph Krogh <andreas@visena.com>
parent: Asya Nevra Buyuksoy <ayisan1096@gmail.com>
0 siblings, 0 replies; 15+ messages in thread
From: Andreas Joseph Krogh @ 2020-02-07 14:19 UTC (permalink / raw)
To: pgsql-performance@lists.postgresql.org
På fredag 07. februar 2020 kl. 15:16:13, skrev Asya Nevra Buyuksoy <
ayisan1096@gmail.com <mailto:ayisan1096@gmail.com>>:
Andreas Joseph Krogh wrote on 2/7/2020 8:41 AM:
På fredag 07. februar 2020 kl. 14:23:35, skrev Asya Nevra Buyuksoy <
ayisan1096@gmail.com <mailto:ayisan1096@gmail.com>>:
My guess is the time is spent in the client retrieving the data, not in the DB
itself. Are you on a slow network?
It works in my local area and speed is 1 Gbps. When I use another local
computer that has SSD disk the query execution time reduced to 12 seconds. But
this query has to execute my local computer.
What client are you using?
--
Andreas Joseph Krogh
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: TOAST table performance problem
@ 2020-02-07 14:42 Andreas Joseph Krogh <andreas@visena.com>
0 siblings, 1 reply; 15+ messages in thread
From: Andreas Joseph Krogh @ 2020-02-07 14:42 UTC (permalink / raw)
To: Asya Nevra Buyuksoy <ayisan1096@gmail.com>; +Cc: pgsql-performance@lists.postgresql.org
På fredag 07. februar 2020 kl. 15:35:04, skrev Asya Nevra Buyuksoy <
ayisan1096@gmail.com <mailto: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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: TOAST table performance problem
@ 2020-02-07 14:59 Asya Nevra Buyuksoy <ayisan1096@gmail.com>
parent: Andreas Joseph Krogh <andreas@visena.com>
0 siblings, 1 reply; 15+ messages in thread
From: Asya Nevra Buyuksoy @ 2020-02-07 14:59 UTC (permalink / raw)
To: Andreas Joseph Krogh <andreas@visena.com>; +Cc: pgsql-performance@lists.postgresql.org
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 <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
>
>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: TOAST table performance problem
@ 2020-02-07 15:15 Andreas Joseph Krogh <andreas@visena.com>
parent: Asya Nevra Buyuksoy <ayisan1096@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: Andreas Joseph Krogh @ 2020-02-07 15:15 UTC (permalink / raw)
To: Asya Nevra Buyuksoy <ayisan1096@gmail.com>; +Cc: pgsql-performance@lists.postgresql.org
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;
>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 <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.
^ permalink raw reply [nested|flat] 15+ messages in thread
* Fwd: TOAST table performance problem
@ 2020-02-10 07:52 Asya Nevra Buyuksoy <ayisan1096@gmail.com>
parent: Andreas Joseph Krogh <andreas@visena.com>
0 siblings, 1 reply; 15+ messages in thread
From: Asya Nevra Buyuksoy @ 2020-02-10 07:52 UTC (permalink / raw)
To: pgsql-performance@lists.postgresql.org
---------- 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;
>> 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 <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.
>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Fwd: TOAST table performance problem
@ 2020-02-10 12:31 Luís Roberto Weck <luisroberto@siscobra.com.br>
parent: Asya Nevra Buyuksoy <ayisan1096@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: Luís Roberto Weck @ 2020-02-10 12:31 UTC (permalink / raw)
To: ayisan1096@gmail.com; +Cc: pgsql-performance@lists.postgresql.org
> ---------- Forwarded message ---------
> Gönderen: *Asya Nevra Buyuksoy* <ayisan1096@gmail.com
> <mailto:ayisan1096@gmail.com>>
> Date: 10 Şub 2020 Pzt, 10:51
> Subject: Re: TOAST table performance problem
> To: Andreas Joseph Krogh <andreas@visena.com <mailto: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 <mailto: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 <mailto:ayisan1096@gmail.com>>:
>
> 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 <andreas@visena.com
> <mailto: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 <mailto: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.
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Fwd: TOAST table performance problem
@ 2020-02-10 12:38 Asya Nevra Buyuksoy <ayisan1096@gmail.com>
parent: Luís Roberto Weck <luisroberto@siscobra.com.br>
0 siblings, 1 reply; 15+ messages in thread
From: Asya Nevra Buyuksoy @ 2020-02-10 12:38 UTC (permalink / raw)
To: Luís Roberto Weck <luisroberto@siscobra.com.br>; +Cc: pgsql-performance@lists.postgresql.org
Got it, thanks! I understand and know it that PostgreSQL is not slow, but I
want to a piece of advice how can I load this data fastly :)
Luís Roberto Weck <luisroberto@siscobra.com.br>, 10 Şub 2020 Pzt, 15:31
tarihinde şunu yazdı:
> ---------- 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;
>>> 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 <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.
>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Fwd: TOAST table performance problem
@ 2020-02-10 12:53 Jeff Janes <jeff.janes@gmail.com>
parent: Asya Nevra Buyuksoy <ayisan1096@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: Jeff Janes @ 2020-02-10 12:53 UTC (permalink / raw)
To: Asya Nevra Buyuksoy <ayisan1096@gmail.com>; +Cc: Luís Roberto Weck <luisroberto@siscobra.com.br>; Pgsql Performance <pgsql-performance@lists.postgresql.org>
On Mon, Feb 10, 2020 at 7:38 AM Asya Nevra Buyuksoy <ayisan1096@gmail.com>
wrote:
> Got it, thanks! I understand and know it that PostgreSQL is not slow, but
> I want to a piece of advice how can I load this data fastly :)
>
You haven't told us anything about your client, so what advice can we
offer? Unless the bottleneck is in the libpq library, this is probably not
the right place to ask about it anyway.
Cheers,
Jeff
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Fwd: TOAST table performance problem
@ 2020-02-10 12:59 Asya Nevra Buyuksoy <ayisan1096@gmail.com>
parent: Jeff Janes <jeff.janes@gmail.com>
0 siblings, 0 replies; 15+ messages in thread
From: Asya Nevra Buyuksoy @ 2020-02-10 12:59 UTC (permalink / raw)
To: Jeff Janes <jeff.janes@gmail.com>; +Cc: Luís Roberto Weck <luisroberto@siscobra.com.br>; Pgsql Performance <pgsql-performance@lists.postgresql.org>
Ok, you are right. Thanks for everything.
Jeff Janes <jeff.janes@gmail.com>, 10 Şub 2020 Pzt, 15:54 tarihinde şunu
yazdı:
> On Mon, Feb 10, 2020 at 7:38 AM Asya Nevra Buyuksoy <ayisan1096@gmail.com>
> wrote:
>
>> Got it, thanks! I understand and know it that PostgreSQL is not slow, but
>> I want to a piece of advice how can I load this data fastly :)
>>
>
> You haven't told us anything about your client, so what advice can we
> offer? Unless the bottleneck is in the libpq library, this is probably not
> the right place to ask about it anyway.
>
> Cheers,
>
> Jeff
>
^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2020-02-10 12:59 UTC | newest]
Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-02-07 13:07 TOAST table performance problem Asya Nevra Buyuksoy <ayisan1096@gmail.com>
2020-02-07 13:23 ` Asya Nevra Buyuksoy <ayisan1096@gmail.com>
2020-02-07 13:34 ` Asya Nevra Buyuksoy <ayisan1096@gmail.com>
2020-02-07 13:41 ` Andreas Joseph Krogh <andreas@visena.com>
2020-02-07 13:52 ` MichaelDBA <MichaelDBA@sqlexec.com>
2020-02-07 14:16 ` Asya Nevra Buyuksoy <ayisan1096@gmail.com>
2020-02-07 14:19 ` Andreas Joseph Krogh <andreas@visena.com>
2020-02-07 14:42 Re: TOAST table performance problem Andreas Joseph Krogh <andreas@visena.com>
2020-02-07 14:59 ` Asya Nevra Buyuksoy <ayisan1096@gmail.com>
2020-02-07 15:15 ` Andreas Joseph Krogh <andreas@visena.com>
2020-02-10 07:52 ` Asya Nevra Buyuksoy <ayisan1096@gmail.com>
2020-02-10 12:31 ` Luís Roberto Weck <luisroberto@siscobra.com.br>
2020-02-10 12:38 ` Asya Nevra Buyuksoy <ayisan1096@gmail.com>
2020-02-10 12:53 ` Jeff Janes <jeff.janes@gmail.com>
2020-02-10 12:59 ` Asya Nevra Buyuksoy <ayisan1096@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox