> Heikki Linnakangas wrote:
> On 08.02.2011 10:43, Kevin Grittner wrote:
>> I see that at least three BuildFarm critters don't have UINT64_MAX
> I guess we'll have to just #define it ourselves. Or could we just
> pick another magic value, do we actually rely on
> InvalidSerCommitSeqno being higher than all other values anywhere?
It seemed more robust than a low-end number, based on how it's used.
>> Not sure why coypu is running out of connections.
> Hmm, it seems to choose a smaller max_connections value now, 20
> instead of 30. Looks like our shared memory usage went up by just
> enough to pass that threshold.
> Looks like our shared memory footprint grew by about 2MB with
> default configuration, from 37MB to 39MB. That's quite significant.
> Should we dial down the default of
> max_predicate_locks_per_transaction? Or tweak the sizing of the
> hash tables somehow?
Dialing down max_predicate_locks_per_transaction could cause the user
to see "out of shared memory" errors sooner, so I'd prefer to stay
away from that. Personally, I feel that max_connections is higher
than it should be for machines which would have trouble with the RAM
space, but I suspect I'd have trouble selling the notion that the
default for that should be reduced.
The multiplier of 10 PredXactList structures per connection is kind
of arbitrary. It affects the point at which information is pushed to
the lossy summary, so any number from 2 up will work correctly; it's
a matter of performance and false positive rate. We might want to
put that on a GUC and default it to something lower.
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2011-02-08 13:48:08|
|Subject: Re: [pgsql-general 2011-1-21:] Are there any projects
interested in object functionality? (+ rule bases)|
|Previous:||From: Robert Haas||Date: 2011-02-08 13:05:24|
|Subject: Re: Named restore points|