ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / JPA и наследование
25 сообщений из 108, страница 4 из 5
  4  все
JPA и наследование
    #39328991
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lleming
Участник
head_read читать как heap_read
...
Рейтинг: 0 / 0
18.10.2016, 14:41
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329016
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
llemingможно создать таблицу где tuple должен поместиться в 8Kb, если есть large fields и tuple больше 8Kb то его выкинет в toast table. Если нет large fields то создать таблицу где tuple превысит 8Kb думаю не получится (а оно зачем в таблице иметь больше сотни колонок)Ну вот у меня создает без проблем, 250 же не много совсем? (в DB2, к примеру так не получится - она заставит создавать таблицу в табличном пространстве с увеличенным размером блока, в Oracle можно или в другом табличном пространстве создавать или получить row chaining):

 
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
postgres=# create table t (
postgres(#  a1 varchar(250),
postgres(#  a2 varchar(250),
postgres(#  a3 varchar(250),
postgres(#  a4 varchar(250),
postgres(#  a5 varchar(250),
postgres(#  a6 varchar(250),
postgres(#  a7 varchar(250),
postgres(#  a8 varchar(250),
postgres(#  a9 varchar(250),
postgres(#  a10 varchar(250),
postgres(#  a11 varchar(250),
postgres(#  a12 varchar(250),
postgres(#  a13 varchar(250),
postgres(#  a14 varchar(250),
postgres(#  a15 varchar(250),
postgres(#  a16 varchar(250),
postgres(#  a17 varchar(250),
postgres(#  a18 varchar(250),
postgres(#  a19 varchar(250),
postgres(#  a20 varchar(250),
postgres(#  a21 varchar(250),
postgres(#  a22 varchar(250),
postgres(#  a23 varchar(250),
postgres(#  a24 varchar(250),
postgres(#  a25 varchar(250),
postgres(#  a26 varchar(250),
postgres(#  a27 varchar(250),
postgres(#  a28 varchar(250),
postgres(#  a29 varchar(250),
postgres(#  a30 varchar(250),
postgres(#  a31 varchar(250),
postgres(#  a32 varchar(250),
postgres(#  a33 varchar(250),
postgres(#  a34 varchar(250),
postgres(#  a35 varchar(250),
postgres(#  a36 varchar(250),
postgres(#  a37 varchar(250),
postgres(#  a38 varchar(250),
postgres(#  a39 varchar(250),
postgres(#  a40 varchar(250)
postgres(# );
CREATE TABLE
postgres=# \dt t
        List of relations
 Schema | Name | Type  |  Owner   
--------+------+-------+----------
 public | t    | table | postgres
(1 row)

postgres=#



При этом про "сотню колонок" вы слегка лукавите, мы же не 90-х живем, и однобайтовые кодировки, слава богу, умерли, поэтому на utf8 блок в 8K превращается всего 4K символов (+/- служебная информация), а с utf16 вообще все печально получается.
...
Рейтинг: 0 / 0
18.10.2016, 15:00
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329023
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Андрей Панфилов250 же не много совсем?
все поля текст по 250 - не жизненно.
...
Рейтинг: 0 / 0
18.10.2016, 15:17
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329067
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Андрей ПанфиловBlazkowiczВы о чем вообще???вам лучше знать, про "качественный, открытый к изменениям код и заложеная в архитектуру масштабируемость" писал же не я, соответственно и возник вопрос каким образом сужение projection влияет на качество кода.
Продолжайте нести ахинею. Смотрите не расплескайте по дороге. Удачи.
...
Рейтинг: 0 / 0
18.10.2016, 15:53
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329073
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
Petro123все поля текст по 250 - не жизненно.При должном старании не проблема, однако посыл был несколько в другом, а именно в том, что при определенных условиях _в базе_ производительность-таки зависит от projection.
...
Рейтинг: 0 / 0
18.10.2016, 15:58
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329078
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
BlazkowiczПродолжайте нести ахинею. Смотрите не расплескайте по дороге. Удачи.Не нужно так расстраиваться, просто покажите цифры как "ширина выборки не влияет на производительность", и делу конец. Какой смысл теоретизировать и высасывать умозаключения из пальца, если можно просто взять и измерить?
...
Рейтинг: 0 / 0
18.10.2016, 16:01
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329086
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lleming
Участник
Андрей ПанфиловPetro123все поля текст по 250 - не жизненно.При должном старании не проблема, однако посыл был несколько в другом, а именно в том, что при определенных условиях _в базе_ производительность-таки зависит от projection.

на величину не сильно отличающуюся от нуля
...
Рейтинг: 0 / 0
18.10.2016, 16:06
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329088
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Андрей ПанфиловНе нужно так расстраиваться, просто покажите цифры как "ширина выборки не влияет на производительность", и делу конец. Какой смысл теоретизировать и высасывать умозаключения из пальца, если можно просто взять и измерить?
Да, кто же расстраивается. Я просто больше не вижу смысла именно Вам что-то объяснять. У Вас в каждом сообщении факты вперемешку с чушью. Тратить время на выуживания ценной информации из потока вашего бреда надоело. Приплели какой-то @Embedded к архитектуре. С такой кашей в голове бесполезно соревноваться.
...
Рейтинг: 0 / 0
18.10.2016, 16:07
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329090
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
llemingна величину не сильно отличающуюся от нулятолько не в абстрактном PostgreSQL, а в вашей базе, на вашей схеме, на ваших данных.
...
Рейтинг: 0 / 0
18.10.2016, 16:08
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329101
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
BlazkowiczДа, кто же расстраивается. Я просто больше не вижу смысла именно Вам что-то объяснять. У Вас в каждом сообщении факты вперемешку с чушью. Тратить время на выуживания ценной информации из потока вашего бреда надоело. Приплели какой-то @Embedded к архитектуре. С такой кашей в голове бесполезно соревноваться.Что значит какой-то? Это часть JPA-спецификации, чтобы не fetch=FetchType.LAZY у каждого поля ставить и таскаться с этим мусором, а выделить группу полей в отдельную сущность. Это вы "прилепили" "качественный, открытый к изменениям код и заложеная в архитектуру масштабируемость" к количеству колонок в projection, и каким образом это прилепилось выяснить так и не удалось.
...
Рейтинг: 0 / 0
18.10.2016, 16:17
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329108
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lleming
Участник
Андрей Панфиловllemingна величину не сильно отличающуюся от нулятолько не в абстрактном PostgreSQL, а в вашей базе, на вашей схеме, на ваших данных.

А зачем мне оптимизировать абстрактную БД которая только у вас в голове и доступ к ней только у вас.
...
Рейтинг: 0 / 0
18.10.2016, 16:22
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329115
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
llemingА зачем мне оптимизировать абстрактную БД которая только у вас в голове и доступ к ней только у вас.Это ваши слова?

llemingоб этом уже говорилось что чтение построчное (Postgres) разницы нет для DB читать одну колонку или все сразу
...
Рейтинг: 0 / 0
18.10.2016, 16:28
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329121
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lleming
Участник
Да. А что там не так?
...
Рейтинг: 0 / 0
18.10.2016, 16:32
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329131
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
lleming,

будет разница в производительность между чтением всех колонок из таблицы и только тех, что не попали в TOAST (мы вроде как выяснили что в TOAST попадают не только совсем уж здоровые колонки, а вообще все что в 8K блок не поместилось)?
...
Рейтинг: 0 / 0
18.10.2016, 16:40
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329153
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lleming
Участник
Андрей Панфиловlleming,
будет разница в производительность между чтением всех колонок из таблицы и только тех, что не попали в TOAST (мы вроде как выяснили что в TOAST попадают не только совсем уж здоровые колонки, а вообще все что в 8K блок не поместилось)?

это мы не выяснили, это вы так поняли. (вообще почитайте ссылку которую вы привели про toast таблицы)

так я вам привел пример реальные цифры.

в тоаст попадает только одня таблица их нескольких сотен.
паттерн ее использования говорит что не особо то даже из toast читается только наиболее длинные записи коих в процентном соотншении немного. уменьшать выборку колонок там уже некуда.

Т.е. разница возможно и есть, но никто ее не видел и измерить тоже не удается.



PS.
Оптимизация абстрактных БД (600р/ч)
...
Рейтинг: 0 / 0
18.10.2016, 16:56
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329184
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
llemingТ.е. разница возможно и есть, но никто ее не видел и измерить тоже не удается. Почему не удается? Вот я беру оракл и специально делаю широкую таблицу, чтобы ее строки попадали в несколько блоков:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
SQL> create table t1 as 
select 
 lpad('x',4000,'x') a1, lpad('x',4000,'x') a2,
 lpad('x',4000,'x') a3, lpad('x',4000,'x') a4, 
 lpad('x',4000,'x') a5, lpad('x',4000,'x') a6 from dual
connect by level <= 1000;

Table created.



Чтение только первой колонки:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
SQL> select a1 from t1;

1000 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 3617692013

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  1000 |  3907K|   921   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| T1   |  1000 |  3907K|   921   (1)| 00:00:01 |
--------------------------------------------------------------------------


Statistics
----------------------------------------------------------
          5  recursive calls
          0  db block gets
       3958  consistent gets
       6745  physical reads
          0  redo size
      26198  bytes sent via SQL*Net to client
       1278  bytes received via SQL*Net from client
         68  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       1000  rows processed

SQL>



чтение всех колонок:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
SQL> select * from t1;

1000 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 3617692013

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  1000 |    22M|   921   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| T1   |  1000 |    22M|   921   (1)| 00:00:01 |
--------------------------------------------------------------------------


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       6727  consistent gets
       9960  physical reads
          0  redo size
   24113229  bytes sent via SQL*Net to client
       1278  bytes received via SQL*Net from client
         68  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       1000  rows processed



чтение колонок из разных блоков:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
SQL> select a1, a6 from t1;

1000 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 3617692013

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  1000 |  7814K|   921   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| T1   |  1000 |  7814K|   921   (1)| 00:00:01 |
--------------------------------------------------------------------------


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       6727  consistent gets
       9780  physical reads
          0  redo size
      34280  bytes sent via SQL*Net to client
       1278  bytes received via SQL*Net from client
         68  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       1000  rows processed



Разница есть, и я бы не сказал что она несущественная.
...
Рейтинг: 0 / 0
18.10.2016, 17:37
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329196
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Андрей ПанфиловРазница есть, и я бы не сказал что она несущественная.Смотрим в плане колонки стоимости: проц и время - одинаковы во всех вариантах.
За килобайты использованной памяти IBM-у уже никто не платит, на трафиковых тарифах канал к СУБД, обычно, не используют.
Ы?
...
Рейтинг: 0 / 0
18.10.2016, 17:49
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329220
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
Basil A. SidorovСмотрим в плане колонки стоимости: проц и время - одинаковы во всех вариантах.Наверное потому что plan hash value одинаковый, да? а вот разница в IO (physical reads и consistent gets) налицо.
...
Рейтинг: 0 / 0
18.10.2016, 18:07
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329234
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lleming
Участник
я вот мерил на реале (Postgres)

и получилось (без сети)
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
explain (analyze, timing)
select * from table_with_large_object limit 100;

explain (analyze, timing)
select 
  not_large_object1, 
  not_large_object2, 
  not_large_object3
from table_with_large_object limit 100;




Не вижу никакой разницы. Отсюда вывод что время выполнения запроса даже при наличинии toast table увеличивается на величину сравнимую с погрешностью доступа к диску, т.е на неизмеряемую величину.

Ваш абстрактный случай абсолютно неинтересный. Всего 1000 записей это ни очем, там всегда seq scan будет.
Если там 10млн строк то естесно будут сильно медленней.
НО тут возникает вопрос кому нахрен на клиенте 10млн строк нужно сразу да еще и с large objects (Мы же про хибернейт помним)?

А если это индекс скан то при извлечении строки
1 после поиска по индексу, чтение самой таблицы и только затем toast tаble
2 не факт что это строка попадет в toast (на реальных данных вот уменя с вероятность менее 50% попадает в toast )
3 а про то что и как в кэш попадет и как здесь повезет вообще может сильно резульат поменять (по дешевую память уже было)
...
Рейтинг: 0 / 0
18.10.2016, 18:29
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329245
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Андрей Панфилова вот разница в IO (physical reads и consistent gets) налицо.До тех пор, пока ни то, ни другое не упёрлись в возможности хранилища - это пофигу.
Особенно с учётом того, что данных миллисекундной точности фактического времени выполнения запроса вы не приводите, общей загрузки базы - тоже не видно, а без этих данных невозможно понять - требуется оптимизация или опять будем яйца (Фаберже) полировать.
...
Рейтинг: 0 / 0
18.10.2016, 18:40
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329320
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
llemingя вот мерил на реале (Postgres)

и получилось (без сети)
Код: plsql
1.
explain (analyze, timing)


Вы уверены, что ваш прибор показывает правильные данные? на 8.4 analyze показывает полную фигню:

 
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
тут попытка сгенерировать таблицу на 5Gb, она оказалась неудачной, потому что 5Gb не получилось

postgres=# create table t1 as select lpad('x',100,'x') as a1, lpad('x', 1024*1024, 'x') as a2 from generate_series(1,5*1024);
SELECT
postgres=# select sum(length(a2)) from t1;
    sum     
------------
 5368709120
(1 row)

postgres=# select sum(length(a2))/1024/1024/1024 from t1;
 ?column? 
----------
        5
(1 row)
-bash-4.1$ du -sh /var/lib/pgsql/data/
105M	/var/lib/pgsql/data/

здесь уже удачная попытка:

postgres=# create table t1 as select lpad('x',100,'x') as a1, 
                 (SELECT array_to_string(ARRAY(SELECT chr((65 + round(random() * 25)) :: integer) 
                   FROM generate_series(1,1024*1024)), '')
                 ) as a2 from generate_series(1,5*1024);

-bash-4.1$ du -sh /var/lib/pgsql/data/
5.4G	/var/lib/pgsql/data/


А дальше analyze показывает чудеса:

postgres=# explain analyze select a1 from t1;
                                              QUERY PLAN                                              
------------------------------------------------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..145.20 rows=5120 width=101) (actual time=0.004..0.851 rows=5120 loops=1)
 Total runtime: 1.200 ms
(2 rows)

postgres=# explain analyze select a2 from t1;
                                             QUERY PLAN                                              
-----------------------------------------------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..145.20 rows=5120 width=18) (actual time=0.007..1.212 rows=5120 loops=1)
 Total runtime: 1.550 ms
(2 rows)

т.е. 5Gb якобы вычитывается за 1.5ms - памяти на виртуалке всего-то 1Gb, так что безумный вариант 
с кешированием и так отпадает, а вот уже более-менее реальные данные:

postgres=# explain analyze select sum(length(a2)) from t1;
                                                 QUERY PLAN                                                 
------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=158.00..158.01 rows=1 width=18) (actual time=35787.137..35787.138 rows=1 loops=1)
   ->  Seq Scan on t1  (cost=0.00..145.20 rows=5120 width=18) (actual time=0.004..24.888 rows=5120 loops=1)
 Total runtime: 35790.589 ms
(3 rows)

...
Рейтинг: 0 / 0
18.10.2016, 20:38
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329336
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lleming
Участник
тут наверное следует упомянуть что Postgres прежде чем в toast записывать сжимает данные и проверяет еще раз а стоит ли toast Записывать или просто tuple записать в page


т.е. строки типа 'xxxxxxxxxxxxxxxxxxxxxxxxxx........' очень хорошо сжимаются у меня файл 1.08Гб ужался до 1.2Мб
...
Рейтинг: 0 / 0
18.10.2016, 21:20
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329456
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
lleming,

ну а с 5Gb "хороших" данных как быть? Ну ладно, установил 9.5 чтобы быть на одной волне:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
postgres=# explain (analyze,timing) select a1 from t1;
                                              QUERY PLAN                                              
------------------------------------------------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..145.20 rows=5120 width=101) (actual time=0.008..1.311 rows=5120 loops=1)
 Planning time: 0.048 ms
 Execution time: 1.669 ms
(3 rows)

postgres=# explain (analyze,timing) select a2 from t1;
                                             QUERY PLAN                                              
-----------------------------------------------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..145.20 rows=5120 width=18) (actual time=0.006..1.465 rows=5120 loops=1)
 Planning time: 0.064 ms
 Execution time: 1.794 ms
(3 rows)



и стало понятно почему вы не видите разницы: вы получаете какие-то два числа - "Planning time" и "Execution time", и на основе этих двух чисел делаете вывод. Проблема первая: что такое "Planning time" и "Execution time" никто не знает - из документации следует только то, что "Planning time" и "Execution time" - это нечто, что выводит команда explain, и здесь я готов согласиться, что projection не влияет на "Execution time", выводимый командой explain - эксперимент провели, явнойожидаемой корреляции не заметно (как экспериментатор я ожидал что цифры будут соответствовать количеству читаемых блоков, а они не соответствуют). Проблема вторая: "Execution time", выводимый командой explain, никакого отношения к производительности не имеет. Поясню. В Oracle execution time (что это такое в документации отражено: http://docs.oracle.com/cd/A97630_01/server.920/a96533/sqltrace.htm) для селектов почти всегда 0, потому что для селектов фаза execute подразумевает открытие курсора и получение текущего SCN, а вся работа происходит в фазе fetch (Retrieves rows returned by a query) и в PostgreSQL аналогично - ну не может он 5Gb данных вычитать за 1.5ms.
...
Рейтинг: 0 / 0
19.10.2016, 03:30
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329458
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
BlazkowiczАндрей ПанфиловК вам вопрос: а вы из какого года прибыли? из 2000? Сейчас скорость IO у СУБД перекрывает скорость сетевых интерфейсов. Про поколоночное хранение в СУБД слышали что-нибудь? А про InMemory database?
Офигеть. Вы опять включили умника с кучей терминов, которые к вопросу отношения не имееют. Интерфейс с удаленной базой всегда был проблемой, даже в нулевых. Поэтому базу старались не отделять особо от middle tier. Но это становиться проблемой в нагруженом кластере, так как RDBMS одна и распределяется очень хреново, поэтому с ней нужен гигабитный интерфейс и желательно не один. Но, вашу ж мать, сейчас 10 гигабитный Ethernet не проблема. А вы собираетсь результаты запроса в пакеты укладывать.

А про "колоночное хранение" и прочую чушь, не надо тут. Мы всё ещё обсуждаем ORM, который пока что подразумевает классический RDBMS с нормализацией.
Может вам к вендору сходить и рассказать какие там у него лохи сидят: Exadata Smart Scan Projection Limitation ?
...
Рейтинг: 0 / 0
19.10.2016, 03:50
| Ответить | Цитировать | Написать  
JPA и наследование
    #39329597
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lleming
Участник
Андрей Панфилови стало понятно почему вы не видите разницы: вы получаете какие-то два числа - "Planning time" и "Execution time", и на основе этих двух чисел делаете вывод. Проблема первая: что такое "Planning time" и "Execution time" никто не знает - из документации следует только то, что "Planning time" и "Execution time" - это нечто, что выводит команда explain, и здесь я готов согласиться, что projection не влияет на "Execution time", выводимый командой explain - эксперимент провели, явнойожидаемой корреляции не заметно (как экспериментатор я ожидал что цифры будут соответствовать количеству читаемых блоков, а они не соответствуют). Проблема вторая: "Execution time", выводимый командой explain, никакого отношения к производительности не имеет. Поясню. В Oracle execution time (что это такое в документации отражено: http://docs.oracle.com/cd/A97630_01/server.920/a96533/sqltrace.htm) для селектов почти всегда 0, потому что для селектов фаза execute подразумевает открытие курсора и получение текущего SCN, а вся работа происходит в фазе fetch (Retrieves rows returned by a query) и в PostgreSQL аналогично - ну не может он 5Gb данных вычитать за 1.5ms.

это в качестве нормы для сложного запроса прогнать 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.

По сути тут вы даже не меряете IO поскольку его и нет. Вся таблица в кэше это раз, большие данные сжаты здорово это два. Здесь измерено как быстро работает RAM и как быстро процессор может распраковать данные. Даже с IO, для для первого чтения это всего 54 страницы по 8Kb
милисекунды даже для HDD

"Planning time" - принято считать что парсинг запроса, валидация, построение AST.
"execution time" - как я понял это время от начала транзакции до ее завершения.

Пример к реальной жизни имеет малое отношение.
...
Рейтинг: 0 / 0
19.10.2016, 10:34
| Ответить | Цитировать | Написать  
25 сообщений из 108, страница 4 из 5
  4  все
Форумы / Java [игнор отключен] [закрыт для гостей] / JPA и наследование
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&msg=39329196&tid=2123600]:
 0ms
get settings:
 9ms
get forum list:
 16ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 169ms
get topic data:
 14ms
get forum data:
 3ms
get page messages:
 63ms
get tp. blocked users:
 2ms
others: 233ms
total:  517ms
созд. / загр.: 517ms
x
x
Закрыть


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