Re: partitioned table set and indexes

Поиск
Список
Период
Сортировка
От Andreas Kretschmer
Тема Re: partitioned table set and indexes
Дата
Msg-id 1493794655.315218.1449879621677.JavaMail.open-xchange@oxweb02.ims-firmen.de
обсуждение исходный текст
Ответ на Re: partitioned table set and indexes  (Rick Otten <rottenwindfish@gmail.com>)
Ответы Re: partitioned table set and indexes  (Rick Otten <rottenwindfish@gmail.com>)
Список pgsql-performance
> Rick Otten <rottenwindfish@gmail.com> hat am 11. Dezember 2015 um 23:09
> geschrieben:

>
> The query performance hit for sequence scanning isn't all that terrible,
> but I'd rather understand and get rid of the issue if I can, now, before I
> run into it again in a situation where it is crippling.

i think, you should try to understand how the planner works.

a simple example:

test=# create table foo (id serial primary key, val text);
CREATE TABLE
test=*# insert into foo (val) select repeat(md5(1::text), 5);
INSERT 0 1
test=*# analyse foo;
ANALYZE
test=*# explain analyse select val from foo where id=1;
                                          QUERY PLAN
-----------------------------------------------------------------------------------------------
 Seq Scan on foo  (cost=0.00..1.02 rows=1 width=164) (actual time=0.006..0.007
rows=1 loops=1)
   Filter: (id = 1)
   Rows Removed by Filter: 1
 Planning time: 0.118 ms
 Execution time: 0.021 ms
(5 rows)


As you can see a seq-scan. It's a small table, costs ..1.02.

Adding one row:

test=*# insert into foo (val) select val from foo;
INSERT 0 1
test=*# analyse foo;
ANALYZE
test=*# explain analyse select val from foo where id=1;
                                          QUERY PLAN
-----------------------------------------------------------------------------------------------
 Seq Scan on foo  (cost=0.00..1.02 rows=1 width=164) (actual time=0.006..0.007
rows=1 loops=1)
   Filter: (id = 1)
   Rows Removed by Filter: 1
 Planning time: 0.118 ms
 Execution time: 0.021 ms
(5 rows)


The same plan. Adding 2 rows:

test=*# insert into foo (val) select val from foo;
INSERT 0 2
test=*# analyse foo;
ANALYZE
test=*# explain analyse select val from foo where id=1;
                                          QUERY PLAN
-----------------------------------------------------------------------------------------------
 Seq Scan on foo  (cost=0.00..1.05 rows=1 width=164) (actual time=0.220..0.277
rows=1 loops=1)
   Filter: (id = 1)
   Rows Removed by Filter: 3
 Planning time: 0.149 ms
 Execution time: 0.453 ms
(5 rows)


The same plan. Adding more rows:

test=*# insert into foo (val) select val from foo;
INSERT 0 4
test=*# insert into foo (val) select val from foo;
INSERT 0 8
test=*# insert into foo (val) select val from foo;
INSERT 0 16
test=*# insert into foo (val) select val from foo;
INSERT 0 32
test=*# insert into foo (val) select val from foo;
INSERT 0 64
test=*# insert into foo (val) select val from foo;
INSERT 0 128
test=*# insert into foo (val) select val from foo;
INSERT 0 256
test=*# insert into foo (val) select val from foo;
INSERT 0 512
test=*# insert into foo (val) select val from foo;
INSERT 0 1024
test=*# insert into foo (val) select val from foo;
INSERT 0 2048
test=*# insert into foo (val) select val from foo;
INSERT 0 4096
test=*# analyse foo;
ANALYZE
test=*# explain analyse select val from foo where id=1;
                                                   QUERY PLAN
----------------------------------------------------------------------------------------------------------------
 Index Scan using foo_pkey on foo  (cost=0.28..8.30 rows=1 width=164) (actual
time=0.007..0.008 rows=1 loops=1)
   Index Cond: (id = 1)
 Planning time: 0.120 ms
 Execution time: 0.024 ms
(4 rows)


We got a new plan! Index-Scan now. We are looking now in pg_class to see how
many rows and pages we have:

test=*# select relpages, reltuples from pg_class where relname = 'foo';
 relpages | reltuples
----------+-----------
      200 |      8192
(1 row)

How large ist the Index?

test=*# select relpages, reltuples from pg_class where relname = 'foo_pkey';
 relpages | reltuples
----------+-----------
       25 |      8192
(1 row)



So, now it's cheaper to read the index and than do an index-scan on the heap to
read one record (our where-condition is on the primary key, so only one row
expected, one page have to read with random access)



It's simple math! If you want to learn more you can find a lot about that via
google:

https://www.google.de/?gws_rd=ssl#q=explaining+explain


В списке pgsql-performance по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Advise needed for a join query with a where conditional
Следующее
От: Rick Otten
Дата:
Сообщение: Re: partitioned table set and indexes