From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Jeremy Schneider <schnjere(at)amazon(dot)com>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Planning performance problem (67626.278ms) |
Date: | 2021-04-21 14:37:05 |
Message-ID: | 767433.1619015825@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> FWIW, here's a simple test case that shows the problem in current master.
This isn't telling the whole story. That first EXPLAIN did set the killed
bits in the index, so that subsequent ones are fairly fast, even without
VACUUM:
regression=# explain select * from a where a < 10000000;
QUERY PLAN
------------------------------------------------------------
Seq Scan on a (cost=0.00..169247.71 rows=9998977 width=4)
Filter: (a < 10000000)
(2 rows)
Time: 3711.089 ms (00:03.711)
regression=# explain select * from a where a < 10000000;
QUERY PLAN
------------------------------------------------------------
Seq Scan on a (cost=0.00..169247.71 rows=9998977 width=4)
Filter: (a < 10000000)
(2 rows)
Time: 230.094 ms
Admittedly this is still more than after VACUUM gets rid of the
index entries altogether:
regression=# vacuum a;
VACUUM
Time: 2559.571 ms (00:02.560)
regression=# explain select * from a where a < 10000000;
QUERY PLAN
-------------------------------------------------
Seq Scan on a (cost=0.00..0.00 rows=1 width=4)
Filter: (a < 10000000)
(2 rows)
Time: 0.698 ms
However, I'm skeptical that any problem actually remains in
real-world use cases.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Luca Ferrari | 2021-04-22 19:45:15 | hint in determining effective_io_concurrency |
Previous Message | David Rowley | 2021-04-21 14:14:21 | Re: Planning performance problem (67626.278ms) |