Re: uso de Include en los indices

Hola Lista

Verificando lo expresado por Alvaro (cito):

" Por ejemplo puedes incluir columnas adicionales en índices UNIQUE (en
las cuales no se verificará unicidad), o incluir columnas que no son
indexables. "

alter table test add column id serial;

vacuum full analyze test;

explain (ANALYZE,BUFFERS,TIMING) select cantidad,mes from test where
id=345654

Gather (cost=1000.00..27210.10 rows=1 width=8) (actual
time=176.955..181.588 rows=1 loops=1)
Workers Planned: 2
Workers Launched: 2
Buffers: shared read=19460
-> Parallel Seq Scan on test (cost=0.00..26210.00 rows=1 width=8)
(actual time=118.910..169.480 rows=0 loops=3)
Filter: (id = 345654)
Rows Removed by Filter: 1200000
Buffers: shared read=19460
Planning Time: 1.593 ms
Execution Time: 181.616 ms

create unique index concurrently idx_unique_test_id on test(id);

explain (ANALYZE,BUFFERS,TIMING) select cantidad,mes from test where
id=345654;

Index Scan using idx_unique_test_id on test (cost=0.09..2.29 rows=1
width=8) (actual time=0.042..0.042 rows=1 loops=1)
Index Cond: (id = 345654)
Buffers: shared read=4
Planning Time: 0.242 ms
Execution Time: 0.064 ms

create unique index concurrently idx_unique_test_id2 on test(id) include
(mes,cantidad);

explain (ANALYZE,BUFFERS,TIMING) select cantidad,mes from test where
id=345654

Index Only Scan using idx_unique_test_id2 on test (cost=0.09..2.29 rows=1
width=8) (actual time=0.044..0.044 rows=1 loops=1)
Index Cond: (id = 345654)
Heap Fetches: 1
Buffers: shared read=4
Planning Time: 0.221 ms
Execution Time: 0.058 ms

SELECT

nspname,relname,pg_relation_size(c.oid),pg_size_pretty(pg_relation_size(c.oid))
as "size"
from pg_class c left join pg_namespace n on ( n.oid=c.relnamespace)
where nspname not in ('pg_catalog','information_schema') and relname ilike
'%test%'
order by pg_relation_size(c.oid) desc;

public;test;159416320;152 MB
*public;idx_unique_test_id2;113418240;108 MB*
public;idx_test_mes;80887808;77 MB
public;idx_test_mes2;80887808;77 MB
*public;idx_unique_test_id;80887808;77 MB*
public;test_id_seq;8192;8192 bytes

en efecto para el caso de unique se se aprecia su funcionamiento (y la
diferencia de tamaño). Muchas Gracias!

El mar., 23 de jun. de 2020 a la(s) 11:07, Alvaro Herrera (
alvherre(at)2ndquadrant(dot)com) escribió:

> Hellmuth Vargas escribió:
> > Hola Diego
> >
> > Gracias por la respuesta, pero.. y qué ventaja tendria? pues lo mismo se
> > logra con un índice compuesto e incluso este último permitirá filtrar
> > además por el otro campo, e incluso el optimizador prefirió el índice
> > compuesto.
>
> Por ejemplo puedes incluir columnas adicionales en índices UNIQUE (en
> las cuales no se verificará unicidad), o incluir columnas que no son
> indexables.
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

--
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate