Robert Haas <robertmh...@gmail.com> writes:
> Nice. What was the overall effect on memory consumption?
Before:
cspell: 31352608 total in 3814 blocks; 37432 free (6 chunks); 31315176 used
After:
cspell: 16214816 total in 1951 blocks; 13744 free (12 chunks); 16201072 used
This is on a 32-bit machine that uses MAXALIGN 8, and I also had
enable_cassert on (hence extra palloc chunk overhead) so it may be
overstating the amount of savings you'd see in production. But it's
in the same ballpark as what Pavel reported originally. AFAICT
practically all of the useful savings comes from the one place he
targeted originally, and the other changes are just marginal gravy.
Before I throw it away, here's some data about the allocations that
go through that code on the Czech dictionary. First column is number
of calls of the given size, second is requested size in bytes:
1 1
695 2
1310 3
1965 4
2565 5
1856 6
578 7
301 8
7 9
2 10
707733 12
520 16
107035 20
16 24
22606 28
3 32
8814 36
59 40
4305 44
2 48
2238 52
2 56
1236 60
20 64
816 68
599 76
1 80
408 84
9 88
334 92
2 96
246 100
1 104
164 108
13 112
132 116
110 124
1 128
107 132
3 136
81 140
1 144
77 148
40 156
46 164
29 172
39 180
2 184
35 188
31 196
19 204
16 212
12 220
10 228
3 244
1 304
1 400
1 1120
The spikes at 12/20/28 bytes correspond to SPNodes with 1/2/3 data
items.
BTW, on a 64-bit machine we're really paying through the nose for the
pointers in SPNodeData --- the pointers are bad enough, and their
alignment effects are worse. If we were to try to change this over to
a pointer-free representation, we could probably replace those pointers
by 32-bit offsets, which would save a full factor of 2 on 64-bit.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
