Re: Seq scans status update
От | Tom Lane |
---|---|
Тема | Re: Seq scans status update |
Дата | |
Msg-id | 2852.1179421403@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Seq scans status update (Heikki Linnakangas <heikki@enterprisedb.com>) |
Ответы |
Re: Seq scans status update
|
Список | pgsql-patches |
Heikki Linnakangas <heikki@enterprisedb.com> writes: > I've completed a set of performance tests on a test server. The server > has 4 GB of RAM, of which 1 GB is used for shared_buffers. Perhaps I'm misreading it, but these tests seem to show no improvement worth spending any effort on --- some of the tests improve a bit but many get worse, and that's for tests allegedly designed to highlight the improvement; there's been no attempt to measure the distributed cost of the additional logic in scenarios where it's not helpful. To say nothing of the likelihood that it will be flat-out counterproductive in yet other scenarios. regression=# select id,sum(rt),count(*) from times group by id; id | sum | count ------------+-----------------+------- 10G | 01:15:53.497114 | 20 10Gpatched | 01:12:51.749906 | 20 2G | 00:11:54.343741 | 20 2Gpatched | 00:11:32.482733 | 20 (4 rows) Should we not just reject the patch and move on to something more useful? regards, tom lane
В списке pgsql-patches по дате отправления: