ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / JPA и наследование
8 сообщений из 108, страница 5 из 5
  5  все
JPA и наследование
    #39329605
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
llemingПример к реальной жизни имеет малое отношение.
+1
и к теме про JPA тоже
...
Рейтинг: 0 / 0
19.10.2016, 10:45
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329620
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
llemingэто в качестве нормы для сложного запроса прогнать expain (analyze, timing).

Если хотите узнать сколько будет читаться при этом блоков то
Код: plsql
1.
explain (analyze, buffers, timing) select a1 from t1;


И можно будет увидеть
" Buffers: shared hit=53" а это значит что 53 * 8 = 424Kb
Код: plsql
1.
select pg_size_pretty(pg_relation_size('t1'))


результат 424Kb


Цифры соотвествуют если у вас тысяча записей всего и т.к. никаких toast нет таблиц поскольку, данные сжимаются легко и непринужденно, такая таблица с 1000 записей у меня 424Kb весит и если у вас для postgres стоит по дефолту, вся умещается в кэше, о чем говорит shared hits.

Нет, данные не "пожаты" и не в кеше, потому что в итоге все (5Gb) забито рандомом, а на виртуалке всего 1Gb памяти - врет прибор:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
postgres=# explain (analyze, buffers, timing) select a1 from t1;
                                              QUERY PLAN                                              
------------------------------------------------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..145.20 rows=5120 width=101) (actual time=1.244..8.651 rows=5120 loops=1)
   Buffers: shared hit=3 read=91
 Planning time: 2.092 ms
 Execution time: 9.198 ms
(4 rows)

postgres=# explain (analyze, buffers, timing) select sum(length(a1)) from t1;
                                                 QUERY PLAN                                                 
------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=170.80..170.81 rows=1 width=101) (actual time=2.639..2.639 rows=1 loops=1)
   Buffers: shared hit=94
   ->  Seq Scan on t1  (cost=0.00..145.20 rows=5120 width=101) (actual time=0.010..0.577 rows=5120 loops=1)
         Buffers: shared hit=94
 Planning time: 0.033 ms
 Execution time: 4.097 ms
(6 rows)



ок, вот здесь верим, а вот здесь уже не верим:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
postgres=# explain (analyze, buffers, timing) select a2 from t1;
                                             QUERY PLAN                                              
-----------------------------------------------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..145.20 rows=5120 width=18) (actual time=0.008..0.677 rows=5120 loops=1)
   Buffers: shared hit=94
 Planning time: 0.026 ms
 Execution time: 0.947 ms
(4 rows)

postgres=# explain (analyze, buffers, timing) select sum(length(a2)) from t1;
                                                 QUERY PLAN                                                 
------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=170.80..170.81 rows=1 width=18) (actual time=61799.367..61799.368 rows=1 loops=1)
   Buffers: shared hit=17925 read=680754
   ->  Seq Scan on t1  (cost=0.00..145.20 rows=5120 width=18) (actual time=0.007..60.218 rows=5120 loops=1)
         Buffers: shared hit=5 read=89
 Planning time: 0.031 ms
 Execution time: 61802.292 ms
(6 rows)



т.е. explain ограничивается чтением только заголовков, а не читает блоки полностью, точно такой же эффект при использовании octet_length:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
postgres=# explain (analyze, buffers, timing) select sum(octet_length(a2)) from t1;
                                                QUERY PLAN                                                 
-----------------------------------------------------------------------------------------------------------
 Aggregate  (cost=170.80..170.81 rows=1 width=18) (actual time=1.833..1.833 rows=1 loops=1)
   Buffers: shared hit=94
   ->  Seq Scan on t1  (cost=0.00..145.20 rows=5120 width=18) (actual time=0.008..0.724 rows=5120 loops=1)
         Buffers: shared hit=94
 Planning time: 0.035 ms
 Execution time: 1.863 ms
(6 rows)



нужно заставлять explain читать данные, чтобы они хоть как-то были похожи на правду:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
postgres=# explain (analyze, buffers, timing) select get_byte(a2::bytea,10000) from t1;
                                                QUERY PLAN                                                
----------------------------------------------------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..183.60 rows=5120 width=18) (actual time=13.539..51600.203 rows=5120 loops=1)
   Buffers: shared hit=17924 read=680755
 Planning time: 1.035 ms
 Execution time: 51613.460 ms
(4 rows)

postgres=# explain (analyze, buffers, timing) select get_byte(a2::bytea,10000),get_byte(a2::bytea,20000) from t1;
                                                QUERY PLAN                                                
----------------------------------------------------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..222.00 rows=5120 width=18) (actual time=12.059..65106.151 rows=5120 loops=1)
   Buffers: shared hit=716505 read=680759
 Planning time: 2.158 ms
 Execution time: 65122.336 ms
(4 rows)
...
Рейтинг: 0 / 0
19.10.2016, 11:02
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329657
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lleming
Участник
нет не врет.
основная таблица всего 770кб.
поле a2 хранится в toast table в 5Gb

Код: plsql
1.
2.
select a1 from t1;
select sum(length(a1)) from t1;


Зачем здесь читать таблицу toast если эти данные не нужны? Достаточно прочитать 770Kb из кэша.

Код: plsql
1.
explain (analyze, buffers, timing) select sum(octet_length(a2)) from t1;


здесь быстро из за того что получить результат совсем необязательно читать данные, ведь у них нет получателя, а сколько байт в этом поле и так указано в метаданных. Вполне разумная оптимизация. В реале также и сделает postgres. Если и в реале и explain получаем одинаковый, всегда верный (наибыстрейшим способом) результат то как бэ в чем претензии?

Код: plsql
1.
explain (analyze, buffers, timing) select get_byte(a2::bytea,10000) from t1;


Здесь явно нужно преобразовать данные. А для этого нужно их достать с диска.


Код: plsql
1.
explain (analyze, buffers, timing) select a2 from t1;


здесь скорее всего планнер постарался. Раз нет получателя то необязательно и читать данные. (Это как раз интересный случай, возможно даже баг поинтересуюсь в соотвествующем чате.)

Андрей Панфиловнужно заставлять explain читать данные, чтобы они хоть как-то были похожи на правду:


нет.
нужно читать что выводит explain и понимать почему так это произошло.


результаты хорошие предсказуемые.
все в порядке.
...
Рейтинг: 0 / 0
19.10.2016, 11:45
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329849
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
llemingвсе в порядке.что именно в порядке-то? вот смотрите что получается:
вы утверждаете, что в PostgreSQL производительность не зависит от projection (с оговоркой о широких колонках)

я утверждаю, что кроме широких колонок существуют еще широкие таблицы, и на таких таблицах эффект падения производительности вполне может иметь место быть (т.е. я беру референсную СУБД и наблюдаю там описываемый эффект и предлагаю вам воспроизвести)

вы берете прибор "explain", им что-то замеряете и получаете противоречивый (т.е. не соотносящийся с поведением референсной СУБД) результат

я показываю, что ваши измерения были проведены не верно

Наверное после этого следует провести измерения более правильным способом и убедиться в присутствии эффекта.
...
Рейтинг: 0 / 0
19.10.2016, 14:09
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329908
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lleming
Участник
Андрей Панфиловllemingвсе в порядке.что именно в порядке-то? вот смотрите что получается:
вы утверждаете, что в PostgreSQL производительность не зависит от projection (с оговоркой о широких колонках)

я утверждаю, что кроме широких колонок существуют еще широкие таблицы, и на таких таблицах эффект падения производительности вполне может иметь место быть (т.е. я беру референсную СУБД и наблюдаю там описываемый эффект и предлагаю вам воспроизвести)

вы берете прибор "explain", им что-то замеряете и получаете противоречивый (т.е. не соотносящийся с поведением референсной СУБД) результат

я показываю, что ваши измерения были проведены не верно

Наверное после этого следует провести измерения более правильным способом и убедиться в присутствии эффекта.


В порядке значит когда результат предсказуемый. Тогда вполне понятно что можно ожидать.
А вот когда результат непонятный, непредсказуемый это плохо. Это значит что проблема есть и неизвестно какая.

1. Не зависит. С оговоркой в реальном мире и реальное падение производительности на реальных данных и даже в широких таблицах.
2. Существуют эффект падения незначительный, по сути соизмеримый с погрешностью измерения. Легко и просто нивелируемый словом Lazy при необходимости.
3. Я получил четкий, однозначный, предсказуемый результат. То что Вы не в состоянии осознать как пользоваться и интерпретировать результат expain, так читайте доки, у Postgres очень хорошая документация.
4. Не увидел где. Все верно в абсолюте. Я описал почему так происходит. Доки почему так проиходит можно найти на https://www.postgresql.org/docs/9.5/static/index.html
...
Рейтинг: 0 / 0
19.10.2016, 14:54
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329940
Локшин Марк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Локшин Марк
Участник
Если мы работаем с одной таблицей, то использование/неиспользование покрывающего индекса в запросе (что напрямую зависит от ширины выборки) дает рост производительности запроса в десятки раз минимум (на нормальных объемах данных). Если с несколькими - есть нюансы, но рост скорости на порядки также возможен. Здесь ширина выборки гораздо больше решает.
Однако некоторым здесь это кажется несущественным моментом на который нужно забить, и вспоминать только тогда, когда репорты с боевых установок начнут приходить.
...
Рейтинг: 0 / 0
19.10.2016, 15:27
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329964
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lleming
Участник
Локшин МаркЕсли мы работаем с одной таблицей, то использование/неиспользование покрывающего индекса в запросе (что напрямую зависит от ширины выборки) дает рост производительности запроса в десятки раз минимум (на нормальных объемах данных). Если с несколькими - есть нюансы, но рост скорости на порядки также возможен. Здесь ширина выборки гораздо больше решает.
Однако некоторым здесь это кажется несущественным моментом на который нужно забить, и вспоминать только тогда, когда репорты с боевых установок начнут приходить.

возможно даже не только делать покрывающие индексы но и рефакторить БД, приложение
http://martinfowler.com/books/refactoringDatabases.html

Только эти индексы не мантра которую чем больше повторяешь тем быстрее БД работает.

Если навтыкать индексов в таблицу да еще foreing key в ней не один, то на инсертах и делетах БД начнет грустить и иногда печально посматривать в даль.
...
Рейтинг: 0 / 0
19.10.2016, 15:47
| Ответить | Цитировать | Написать  
JPA и наследование
    #39330006
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Локшин Марк,
бла бла бла - одни слова
Локшин Марки вспоминать только тогда, когда репорты с боевых установок начнут приходить.
ты хоть раз ГУИ писал?
...
Рейтинг: 0 / 0
19.10.2016, 16:28
| Ответить | Цитировать | Написать  
8 сообщений из 108, страница 5 из 5
  5  все
Форумы / Java [игнор отключен] [закрыт для гостей] / JPA и наследование
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&msg=39329605&tid=2123600]:
 0ms
get settings:
 8ms
get forum list:
 19ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 147ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 52ms
get tp. blocked users:
 1ms
others: 196ms
total:  441ms
созд. / загр.: 441ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]