From: | Peter Smith <smithpb2250(at)gmail(dot)com> |
---|---|
To: | Japin Li <japinli(at)hotmail(dot)com> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(at)vondra(dot)me>, "Aya Iwata (Fujitsu)" <iwata(dot)aya(at)fujitsu(dot)com>, Timur Magomedov <t(dot)magomedov(at)postgrespro(dot)ru>, shveta malik <shveta(dot)malik(at)gmail(dot)com> |
Subject: | Re: [WIP]Vertical Clustered Index (columnar store extension) - take2 |
Date: | 2025-08-01 07:18:11 |
Message-ID: | CAHut+PvbYbims60CK68hUBQpzVhXtN7e0HYMgnXN5-bBPwaV1g@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 30, 2025 at 9:07 PM Japin Li <japinli(at)hotmail(dot)com> wrote:
>
...
> 3.
> I've also found that the VCI index is not working. Is this the expected
> behavior?
>
> [local]:3209161 postgres=# \d+ t
> Table "public.t"
> Column | Type | Collation | Nullable | Default | Storage | Compression | Stats target | Description
> --------+---------+-----------+----------+---------+----------+-------------+--------------+-------------
> id | integer | | | | plain | | |
> info | text | | | | extended | | |
> Indexes:
> "t_id_idx" vci (id)
> Access method: heap
>
> [local]:3209161 postgres=# SET enable_seqscan TO off;
> SET
> [local]:3209161 postgres=# EXPLAIN SELECT * FROM t WHERE id = 1000;
> QUERY PLAN
> -----------------------------------------------------
> Seq Scan on t (cost=0.00..2084.00 rows=1 width=37)
> Disabled: true
> Filter: (id = 1000)
> (3 rows)
>
Hi Japin. Yes, that's expected behaviour.
VCI is used only when the vci index is defined for all the columns of
your query. In your example there was a table with 2 columns ('id' and
'info') but you only have an index on the 'id' column. If you change
the query then you can see VCI getting used.
E.g.
postgres=# EXPLAIN SELECT id FROM t WHERE id = 1000;
QUERY PLAN
----------------------------------------------------------------------------
Custom Scan (VCI Scan) using tidx on t (cost=0.00..209.00 rows=1 width=4)
Filter: (id = 1000)
(2 rows)
postgres=# EXPLAIN SELECT * FROM t WHERE id = 1000;
QUERY PLAN
----------------------------------------------------
Seq Scan on t (cost=0.00..209.00 rows=1 width=37)
Filter: (id = 1000)
(2 rows)
postgres=# EXPLAIN SELECT id,info FROM t WHERE id = 1000;
QUERY PLAN
----------------------------------------------------
Seq Scan on t (cost=0.00..209.00 rows=1 width=37)
Filter: (id = 1000)
(2 rows)
~~~
You can see this also in the DEBUG logs, from
vci_can_rewrite_custom_scan(), where it checks to see if the attrs are
in the vci index or not.
e.g.
2025-08-01 16:58:20.939 AEST [26528] DEBUG: vci index: target table
"t"(oid=16384) tuples(rows=10000,extents=0)
2025-08-01 16:58:20.939 AEST [26528] DEBUG: vci index: don't match
index "tidx"(oid=16469)
2025-08-01 16:58:20.940 AEST [26528] DEBUG: attrnum = 1 x
2025-08-01 16:58:20.940 AEST [26528] DEBUG: attrnum = 2
======
Kind Regards,
Peter Smith.
Fujitsu Australia
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2025-08-01 07:18:12 | Re: Raw parse tree is not dumped to log |
Previous Message | Chao Li | 2025-08-01 07:16:18 | Re: Trivial patch to fix a typo |