Re: Minmax indexes (timings)
Erik Rijkers <er@xs4all.nl>
From: "Erik Rijkers" <er@xs4all.nl>
To: "Kevin Grittner" <kgrittn@ymail.com>
Cc: "alvherre@2ndquadrant.com" <alvherre@2ndquadrant.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2013-11-15T18:42:17Z
Lists: pgsql-hackers
Attachments
- minmax_sizes_times-20131115.zip (application/zip)
On Fri, November 15, 2013 17:33, Kevin Grittner wrote:
> Erik Rijkers <er@xs4all.nl> wrote:
>
>> Perhaps someone finds these timings useful.
>
>> '--enable-cassert'
>
> Assertions can really distort the timings, and not always equally
> for all code paths. Any chance of re-running those tests without
> that?
>
Fair enough. It seems it doesn't make all that much difference for this case, here are the results:
'--prefix=/var/data1/pg_stuff/pg_installations/pgsql.minmax' '--with-pgport=6444' '--enable-depend' '--with-perl'
'--with-openssl' '--with-libxml'
-- rowcount (size_string): 10_000
368640 | size table | 360 kB
245760 | size btree index | 240 kB
16384 | size minmax index | 16 kB
Total runtime: 0.121 ms
Total runtime: 0.041 ms
Total runtime: 0.039 ms
Total runtime: 0.040 ms
Total runtime: 0.043 ms
Total runtime: 0.041 ms
Total runtime: 0.040 ms
Total runtime: 0.040 ms
Total runtime: 0.948 ms
-- rowcount (size_string): 100_000
3629056 | size table | 3544 kB
2260992 | size btree index | 2208 kB
16384 | size minmax index | 16 kB
Total runtime: 0.082 ms
Total runtime: 0.039 ms
Total runtime: 0.396 ms
Total runtime: 0.252 ms
Total runtime: 0.339 ms
Total runtime: 0.245 ms
Total runtime: 0.240 ms
Total runtime: 0.241 ms
Total runtime: 13.268 ms
-- rowcount (size_string): 1_000_000
36249600 | size table | 35 MB
22487040 | size btree index | 21 MB
57344 | size minmax index | 56 kB
Total runtime: 0.096 ms
Total runtime: 0.039 ms
Total runtime: 0.039 ms
Total runtime: 0.034 ms
Total runtime: 1.975 ms
Total runtime: 1.527 ms
Total runtime: 1.523 ms
Total runtime: 1.519 ms
Total runtime: 145.125 ms
-- rowcount (size_string): 100_000_000
3624779776 | size table | 3457 MB
2246197248 | size btree index | 2142 MB
4456448 | size minmax index | 4352 kB
Total runtime: 0.074 ms
Total runtime: 0.039 ms
Total runtime: 0.040 ms
Total runtime: 0.033 ms
Total runtime: 150.450 ms
Total runtime: 147.039 ms
Total runtime: 145.410 ms
Total runtime: 145.142 ms
Total runtime: 15068.171 ms
-- rowcount (size_string): 1_000_000_000
36247789568 | size table | 34 GB
22461628416 | size btree index | 21 GB
44433408 | size minmax index | 42 MB
Total runtime: 15.454 ms <-- 4x btree
Total runtime: 0.040 ms
Total runtime: 0.040 ms
Total runtime: 0.034 ms
Total runtime: 1502.353 ms <-- 4x minmax
Total runtime: 1482.322 ms
Total runtime: 1489.522 ms
Total runtime: 1481.424 ms
Total runtime: 162213.392 ms <-- seqscan
I'd say minmax indexes give spectacular gains for very small indexsize.
Erik Rijkers
Commits
-
Refactor per-page logic common to all redo routines to a new function.
- f8f4227976a2 9.5.0 cited
-
Reduce use of heavyweight locking inside hash AM.
- 76837c1507cb 9.3.0 cited
-
Scan the buffer pool just once, not once per fork, during relation drop.
- ece01aae4792 9.2.0 cited
-
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
- 9e2a87b62db8 7.1.1 cited