Re: Faster str to int conversion (was Table with large number of int columns, very slow COPY FROM)
On Thu, Jul 19, 2018 at 4:32 PM, Andres Freund wrote: >> 1. Why the error message changes? If there's a good reason, it should >> be done as a separate commit, or at least well-documented in the >> commit message. > > Because there's a lot of "invalid input syntax for type %s: \"%s\"", > error messages, and we shouldn't force translators to have separate > version that inlines the first %s. But you're right, it'd be worthwhile > to point that out in the commit message. It just seems weird that they're bundled together in one commit like this. >> 2. Does the likely/unlikely stuff make a noticeable difference? > > Yes. It's also largely a copy from existing code (scanint8), so I don't > really want to differ here. OK. >> 3. If this is a drop-in replacement for pg_atoi, why not just recode >> pg_atoi this way -- or have it call this -- and leave the callers >> unchanged? > > Because pg_atoi supports a variable 'terminator'. OK. >> 4. Are we sure this is faster on all platforms, or could it work out >> the other way on, say, BSD? > > I'd be *VERY* surprised if any would be faster. It's not easy to write a > faster implmentation, than what I've proposed, and especially not so if > you use strtol() as the API (variable bases, a bit of locale support). OK. Nothing else from me... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: Faster str to int conversion (was Table with large number of int columns, very slow COPY FROM)
On Sat, Jul 7, 2018 at 4:01 PM, Andres Freund wrote: > FWIW, here's a rebased version of this patch. Could probably be polished > further. One might argue that we should do a bit more wide ranging > changes, to convert scanint8 and pg_atoi to be also unified. But it > might also just be worthwhile to apply without those, given the > performance benefit. Wouldn't hurt to do that one too, but might be OK to just do this much. Questions: 1. Why the error message changes? If there's a good reason, it should be done as a separate commit, or at least well-documented in the commit message. 2. Does the likely/unlikely stuff make a noticeable difference? 3. If this is a drop-in replacement for pg_atoi, why not just recode pg_atoi this way -- or have it call this -- and leave the callers unchanged? 4. Are we sure this is faster on all platforms, or could it work out the other way on, say, BSD? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade
On Tue, Nov 21, 2017 at 12:01 PM, Tom Lane wrote: > "Henrik Cednert (Filmlance)" writes: >> The last pg_dump with 8.4 took 212 minutes and 49 seconds.And now with 9.5 >> the very same pg_dump takes 644 minutes and 40 seconds. To it takes about >> three times as long now and I have no idea to why. Nothing in the system or >> hardware other than the pgsql upgrade have change. > > Can you get a profile of where the machine is spending its time during the > dump run? On Linux I'd recommend "perf", but on macOS, hmm ... > You could use Activity Monitor, but as far as I can see that just captures > short-duration snapshots, which might not be representative of a 10-hour > run. XCode's Instruments feature would probably be better about giving > a full picture, but it has a steep learning curve. macOS's "sample" is pretty easy to use and produces text format output that is easy to email. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
