Postgresql 大json数据不会从TOAST快速返回?

Postgresql 大json数据不会从TOAST快速返回?,postgresql,toast,Postgresql,Toast,我的表有四列,它们的数据类型是text、JSON、boolean和timestamp。 我有一张桌子 CREATE TABLE zamazin ( paramuser_id text, paramperson_id integer, paramdata json, paramisdeleted boolean, paramactiontime timestamp without time zone ) paramdata行大小为110KB及以上 当我像这样执行这个查询时 s

我的表有四列,它们的数据类型是text、JSON、boolean和timestamp。 我有一张桌子

CREATE TABLE zamazin
(
  paramuser_id text,
  paramperson_id integer,
  paramdata json,
  paramisdeleted boolean,
  paramactiontime timestamp without time zone
)
paramdata行大小为110KB及以上

当我像这样执行这个查询时

select * from zamazin
需要600秒。 但在分析查询时

"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"
为什么查询要花很长时间,我不明白。我假设这与TOAST结构有关。 我也有1K行,但我的json列大小大约为110KB,可能超过它

当我调查这些执行时间为何如此不同时,我发现了一种新的存储逻辑,如TOAST。 我忽略了TOAST逻辑的一些细节,增加了一些配置,比如共享缓冲区、工作内存、维护内存、每个进程的最大文件内存

但我的查询没有任何性能改进

我不明白为什么会这样。我的表大小是168 MB,但与该表相关的TOAST表大小是123 MB

我的环境是

PostgreSQL 9.4.1
Windows Server 2012 R2 
16 GB RAM
100 GB HardDisk (Not SSD) – I also test SSD hard disk but there is no change in my execution time.
My database size 20 GB.
我的服务器配置

Shared_buffers: 8GB 

( If I understand correctly, PostgreSQL say, 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
我测试了许多客户端,如psql、pgadmin3、pgadmin4和dbeaver,但是我的执行时间没有增加

我怎样才能取得好成绩

我的前端代码是这样的

/* it is a pseudocode*/
    public static List<User> GetUsers()
        {
            User user;
            List<User> users = new List<User>();
            string errMsg = string.Empty;
            string sql = string.Empty;

            sql = @"select * from zamazin  order by paramuser_id asc;";


            }
            try
            {
                Stopwatch sw = new Stopwatch();
                sw.Start();

                DataTable dt = DBHelper.DataTable(sql, null);
                sw.Stop();
                if (sw.ElapsedMilliseconds > 1500) 
                    Debug.WriteLine("Finished " + sw.Elapsed.TotalMilliseconds + " ms");
                if (dt == null)
                    throw new Exception();
                sw.Restart();
                foreach (DataRow rows in dt.Rows)
                {
                    try
                    {
                        user = JsonConvert.DeserializeObject<User>(Convert.ToString(rows["data"]),
                                            DL_General.Jsonsettings);
                        if (user != null)
                        {


                            users.Add(user);
                        }
                    }
                    catch (Exception ex)
                    {
                        ///bla bla
                    }
                }
                sw.Stop();
                if (sw.ElapsedMilliseconds > 1500) 
                       Console.WriteLine(End loop " + sw.Elapsed.TotalMilliseconds + ");

                return users;
            }
            catch (Exception e)
            {
                //bla bla
            }
            return new List<User>();

        }

如果查询执行时间在服务器上测量,则问题一定是网络或客户端花费了很长时间来呈现数据。

您的数据库是本地的吗?还是在远程网络上?如果它在网络上,从zamazin选择*将包括发送100+MB所需的时间。此外,Postgres 9.4将于2月13日结束。我建议尝试升级Postgres并切换到更高效的jsonb数据类型。是的,这是我的本地数据库。我还测试了PG11版本,也测试了jsonb数据类型,但是没有任何变化。当我选择没有json列的数据时,执行时间是95毫秒。当我将所有数据复制到CSV时,过程非常快,但我没有这样做。在对前端的json进行反序列化之后,我想有效地在网页上可视化我的数据;客户机显示这么多数据需要很长时间。TOAST表是压缩的,因此客户端显示的实际数据将远远超过123MB。查询运行时间为0.236毫秒。如果你看到任何缓慢,它肯定不是在服务器端。到底是什么花了600秒?您提到了npgsql。你能告诉我们需要600秒的代码吗?这可能就是问题所在。谢谢您的回答。是的,我用过,但没有变化。它也可能与网络有关。尝试放弃结果:DO$$BEGIN PERFORM*from zamazin;完(元);是的,花了30毫秒:当我分析我的SQL查询时,结果与此相同。但是我想在我的网页上可视化,但是npgsql需要600秒的时间来获取这些数据。是否有快速获取数据的解决方案?那么唯一的解决方案就是向客户端传输较少的数据。谁想看到110KB的数据,除非是图像?也许您可以提取数据库服务器上的相关数据并减少传输。不幸的是,我不能这样做:因为它们都是包含用户信息的相关数据