Большие json данные не возвращаются быстро из TOAST? - PullRequest
Новая
       23

Большие json данные не возвращаются быстро из TOAST?

1 голос
/ 10 февраля 2020

У меня проблемы с таблицей, в которой есть четыре столбца, тип данных которых - текст, JSON, логическое значение и отметка времени. У меня есть таблица типа; 

CREATE TABLE zamazin
(
  paramuser_id text,
  paramperson_id integer,
  paramdata json,
  paramisdeleted boolean,
  paramactiontime timestamp without time zone
)

Размер строки параметров равен 110 КБ и более.

Когда я выполняю этот запрос как; 

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, а может и выше.

Когда я выяснил, почему эти времена выполнения так различны, я обнаружил новый лог c хранения, такой как TOAST. Я пропускаю некоторые детали в логике TOAST c и увеличил некоторые настройки, такие как shared_buffers, work_mem, maintenance_work_mem, max_file_per_process.

Но в моем запросе улучшения не произошло.

Я не понимаю, почему Бывает. Размер моей таблицы составляет 168 МБ, но размер таблицы TOAST, связанной с этой таблицей, составляет 123 МБ.

Моя среда: 

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>();

        }

1 Ответ

1 голос
/ 10 февраля 2020

Если время выполнения запроса измерено на сервере, проблема должна быть связана с сетью или клиентом, для обработки которых требуется много времени.

...