extra_float_digits is the setting whose job changed out from under it. For most of PostgreSQL’s history it forced a choice between floating-point output that was easy to read and output that was exactly right, and you could not have both. Since PostgreSQL 12 you no longer have to choose, which is why the parameter you may remember reaching for is one you now rarely need.
The old arrangement worked like this. A real or double precision value is stored in binary and does not correspond exactly to the decimal you typed; the nearest double to 0.1 is really 0.1000000000000000055.... With the pre-12 default of 0, PostgreSQL printed such values rounded to a fixed width, six significant digits for float4 and fifteen for float8, which was legible but lossy: the text did not necessarily reproduce the stored bits. If you needed values that round-tripped, text that reads back to the identical binary value, you set extra_float_digits = 3 and PostgreSQL emitted up to seventeen digits. That was exact, and it was ugly: 0.1 came back as 0.10000000000000001. Drivers that cared about precision, and pg_dump, which must preserve values exactly, all set 3.
PostgreSQL 12 rewrote float output to compute, for every value, the shortest decimal string that still round-trips to the exact stored number, and made that the behavior for any extra_float_digits greater than 0. The default became 1. So today the default gives you both properties at once: 0.1 prints as 0.1, and that 0.1 reads back to precisely the same double, because it is the shortest string that does. The new format is also markedly faster to produce than the old digit-by-digit rounding, which had become a real bottleneck when a COPY or a large result set carried millions of floats. Values of 1, 2, and 3 now all mean the same thing; 0 restores the old rounded output, and negative values down to -15 round off progressively more.
Two things follow. pg_dump sets extra_float_digits explicitly for exactness, so restores reproduce your floats to the bit regardless of the server’s configured value, and the old folk advice to “set it to 3 for precision” is now a compatibility habit rather than a requirement: on 12 and later it is identical to the default, and it stays useful only when you need one script to produce byte-identical output against both a pre-12 and a modern server.
The other thing is the misconception this parameter attracts. If you are turning extra_float_digits up to make floating-point arithmetic come out exact, for money, say, you are adjusting the wrong thing entirely. It changes how a float is printed, not how it is stored, and a double precision simply cannot hold 0.1 exactly no matter how many or few digits you show. Exact decimal values are a job for numeric, which stores them exactly and does arithmetic on them exactly, at the cost of speed. extra_float_digits is about rendering; it cannot add precision the type never had.
So leave it at 1. The release that made you trade legibility against correctness is behind us, and the default now delivers both. Move it only to speak to something that expects the historical rounded output, or set it to 3 on the specific day you need one piece of SQL to behave identically across a version-12 boundary.