Hi,
On 2021-12-06 08:57:41 +0000, PG Bug reporting form wrote:
> I am auditing a database which has a really huge partitioned table.
> When working on the whole table queries are slower than the cumulated time
> for all partitions, as you can see with the following query. I don't have
> yet timings for more complex operations like group by, but it looks like it
> is slower than it should be.
What makes you think this is a bug?
A lot of the time is spent doing IO:
worker 0 took 440s, of which 249s where spent waiting IO
worker 1 took 440s, of which 252s where spent waiting IO
As ~60% of the time is spent doing IO, optimizing that would be your best
bet. Each worker appears to do roughly ~190MB/s in IO. What kind of storage do
you have, and how fast do you expect it to be?
> " -> Parallel Seq Scan on
> schema.partitioned_table_y2017_07 partitioned_table_43
> (cost=0.00..1265058.13 rows=24648313 width=0) (actual time=0.526..28599.401
> rows=59154890 loops=1)"
> " Buffers: shared hit=64 read=1018511"
> " I/O Timings: read=20446.894"
> " Worker 1: actual time=0.526..28599.401
> rows=59154890 loops=1"
> " Buffers: shared hit=64 read=1018511"
> " I/O Timings: read=20446.894"
Here you have 24648313 rows in 1018511+64 pages, i.e. ~24 rows / page,
~340bytes/row with 8KiB pages. Do you expect rows to be fairly wide and/or
your tables to have a lot of bloat?
Can you show the table definition?
Greetings,
Andres Freund