Wrong plane for limit after group by

From: Денис Смирнов <darthunix(at)gmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Wrong plane for limit after group by
Date: 2017-10-12 00:18:39
Message-ID: CAKEkwroJR2agO+rbpEEJ16=9rgNh8rQHE=gJ23VfoQcDuc7DKg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi,

I've faced a problem that a query without limit works much faster than with
one. Steps to reproduce

create extension pg_trgm;
create table t (id serial, val text, constraint t_pk primary key (id));
insert into t (val) select (random() * 100)::text from generate_series(1,
1000000);
create index t_val_idx on t using gin (val gin_trgm_ops);

quota_patient> explain (analyze,buffers) select id from t where val like (
select '6'::text) group by id;
+--------------------------------------------------------------------------------------------------------------------------------+

| QUERY PLAN

|

|--------------------------------------------------------------------------------------------------------------------------------|

| HashAggregate (cost=6401.14..6451.14 rows=5000 width=4) (actual
time=22.861..22.861 rows=0 loops=1) |
| Group Key: id

|

| Buffers: shared hit=5158

|

| InitPlan 1 (returns $0)

|

| -> Result (cost=0.00..0.01 rows=1 width=32) (actual
time=0.002..0.002 rows=1 loops=1) |
| -> Bitmap Heap Scan on t (cost=50.75..6388.63 rows=5000 width=4)
(actual time=22.835..22.835 rows=0 loops=1) |
| Recheck Cond: (val ~~ $0)

|

| Rows Removed by Index Recheck: 10112

|

| Heap Blocks: exact=5097

|

| Buffers: shared hit=5158

|

| -> Bitmap Index Scan on t_val_idx (cost=0.00..49.50 rows=5000
width=0) (actual time=8.762..8.762 rows=10112 loops=1) |
| Index Cond: (val ~~ $0)

|

| Buffers: shared hit=61

|

| Planning time: 0.166 ms

|

| Execution time: 22.970 ms

|

+--------------------------------------------------------------------------------------------------------------------------------+

EXPLAIN
Time: 0.026s

quota_patient> explain (analyze,buffers) select id from t where val like (
select '6'::text) group by id limit 1;
+-------------------------------------------------------------------------------------------------------------------------------+

| QUERY PLAN

|

|-------------------------------------------------------------------------------------------------------------------------------|

| Limit (cost=0.43..7.41 rows=1 width=4) (actual time=439.561..439.561
rows=0 loops=1) |
| Buffers: shared hit=9105

|

| InitPlan 1 (returns $0)

|

| -> Result (cost=0.00..0.01 rows=1 width=32) (actual
time=0.002..0.002 rows=1 loops=1) |
| -> Group (cost=0.42..34865.93 rows=5000 width=4) (actual
time=439.560..439.560 rows=0 loops=1) |
| Group Key: id

|

| Buffers: shared hit=9105

|

| -> Index Scan using t_pk on t (cost=0.42..34853.43 rows=5000
width=4) (actual time=439.557..439.557 rows=0 loops=1) |
| Filter: (val ~~ $0)

|

| Rows Removed by Filter: 1000000

|

| Buffers: shared hit=9105

|

| Planning time: 0.205 ms

|

| Execution time: 439.610 ms

|

+-------------------------------------------------------------------------------------------------------------------------------+

EXPLAIN
Time: 0.443s

I can't understand why adding limit after group by makes a planner fall to
non optimal plan. I tried to add more work_mem (up to 100Mb) but no effect.
Is it a planner bug?
BTW if I don't use subquery after like everything is ok

quota_patient> explain (analyze,buffers) select id from t where val like '6'
::text group by id limit 1;
+-----------------------------------------------------------------------------------------------------------------------------------------+

| QUERY PLAN

|

|-----------------------------------------------------------------------------------------------------------------------------------------|

| Limit (cost=24.03..24.04 rows=1 width=4) (actual time=23.048..23.048
rows=0 loops=1) |
| Buffers: shared hit=5158

|

| -> Group (cost=24.03..24.04 rows=1 width=4) (actual
time=23.046..23.046 rows=0 loops=1)
|
| Group Key: id

|

| Buffers: shared hit=5158

|

| -> Sort (cost=24.03..24.04 rows=1 width=4) (actual
time=23.046..23.046 rows=0 loops=1)
|
| Sort Key: id

|

| Sort Method: quicksort Memory: 25kB

|

| Buffers: shared hit=5158

|

| -> Bitmap Heap Scan on t (cost=20.01..24.02 rows=1
width=4) (actual time=23.036..23.036 rows=0 loops=1) |
| Recheck Cond: (val ~~ '6'::text)

|

| Rows Removed by Index Recheck: 10112

|

| Heap Blocks: exact=5097

|

| Buffers: shared hit=5158

|

| -> Bitmap Index Scan on t_val_idx (cost=0.00..20.01
rows=1 width=0) (actual time=8.740..8.740 rows=10112 loops=1) |
| Index Cond: (val ~~ '6'::text)

|

| Buffers: shared hit=61

|

| Planning time: 0.190 ms

|

| Execution time: 23.105 ms

|

+-----------------------------------------------------------------------------------------------------------------------------------------+

EXPLAIN
Time: 0.026s

Browse pgsql-performance by date

  From Date Subject
Next Message Neto pr 2017-10-12 01:35:53 Re: blocking index creation
Previous Message Neto pr 2017-10-11 22:54:16 Re: blocking index creation