Re: Partition key causes problem for volatile target list query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Partition key causes problem for volatile target list query
Date: 2023-01-27 00:21:16
Message-ID: 3236211.1674778876@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> I have found an odd behavior --- a query in the target list that assigns
> to a partitioned column causes queries that would normally be volatile
> to return always zero.

Well, if you looked further than the first few rows, it wouldn't be
"always zero". But the select from the partitioned table will read
the first partition first, and that partition will have the rows
with d1=0, by definition.

=# explain select * from case_test2 limit 10;
QUERY PLAN

--------------------------------------------------------------------------------
-----------
Limit (cost=0.00..0.19 rows=10 width=8)
-> Append (cost=0.00..1987.90 rows=102260 width=8)
-> Seq Scan on case_test2_0 case_test2_1 (cost=0.00..478.84 rows=3318
4 width=8)
-> Seq Scan on case_test2_1 case_test2_2 (cost=0.00..480.86 rows=3328
6 width=8)
-> Seq Scan on case_test2_2 case_test2_3 (cost=0.00..484.30 rows=3353
0 width=8)
-> Seq Scan on case_test2_3 case_test2_4 (cost=0.00..32.60 rows=2260
width=8)
(6 rows)

The result appears sorted by d1, but that's an implementation artifact.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-01-27 00:23:04 Re: Something is wrong with wal_compression
Previous Message Andrey Borodin 2023-01-27 00:14:57 Re: Something is wrong with wal_compression