On Thu, 2013-04-11 at 12:22 -0400, Tom Lane wrote:
> We went around on whether we liked this or not, but it seemed to me
> that the discussion came out at the same place Peter had submitted
> to start with. I don't know why he's not committed it, but I have
> no objection to him doing so, as long
Tomas Vondra wrote:
> On 13.4.2013 15:01, Peter Eisentraut wrote:
> > long-term analysis? Maybe you could even use event triggers to have
> > DROP DATABASE do that automatically.
>
> I don't think event triggers are a good solution, although I'm wondering
> how that's supposed to work.
It doesn
On Sat, Apr 13, 2013 at 06:14:28PM +0300, Ants Aasma wrote:
> > CRCs are known to be good for that sort of thing; it's what they were
> > designed for. I'd like to see some evidence that any substitute
> > algorithm has similar properties. Without that, I'm going to vote
> > against this idea.
>
On Sat, Apr 13, 2013 at 5:56 AM, Peter Eisentraut wrote:
> On Sat, 2013-04-06 at 13:20 -0700, Jeff Janes wrote:
> > I've often wanted to know what the autovacuum worker was doing. The
> > process title seems like the best place to get this information, but
> > the process title tells me what dat
On Sat, Apr 13, 2013 at 6:26 PM, Andres Freund wrote:
>> All in all I would say that the performance is worth the loss in
>> detection capability as we are not talking about using the checksum to
>> prove correctness.
>
> Is it actually a loss compared to our 16bit flavor of crc32 we now use?
> I
On 13.4.2013 15:01, Peter Eisentraut wrote:
> On Sat, 2013-04-06 at 21:51 +0200, Tomas Vondra wrote:
>> This more or less works in stable environments, but once you start
>> dropping databases (think of hosting with shared DB server) it gets
>> unusable because after DROP DATABASE the database sudd
On 2013-04-13 18:14:28 +0300, Ants Aasma wrote:
> On Sat, Apr 13, 2013 at 5:58 PM, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2013-04-13 09:14:26 -0400, Bruce Momjian wrote:
> >>> As I understand it, SIMD is just a CPU-optimized method for producing a
> >>> CRC checksum. Is that right? D
On Sat, Apr 13, 2013 at 5:58 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2013-04-13 09:14:26 -0400, Bruce Momjian wrote:
>>> As I understand it, SIMD is just a CPU-optimized method for producing a
>>> CRC checksum. Is that right? Does it produce the same result as a
>>> non-CPU-optimized
On 2013-04-13 10:58:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-04-13 09:14:26 -0400, Bruce Momjian wrote:
> >> As I understand it, SIMD is just a CPU-optimized method for producing a
> >> CRC checksum. Is that right? Does it produce the same result as a
> >> non-CPU-optimized
Andres Freund writes:
> On 2013-04-13 09:14:26 -0400, Bruce Momjian wrote:
>> As I understand it, SIMD is just a CPU-optimized method for producing a
>> CRC checksum. Is that right? Does it produce the same result as a
>> non-CPU-optimized CRC calculation?
> No we are talking about a different
On 2013-04-13 09:14:26 -0400, Bruce Momjian wrote:
> On Fri, Apr 12, 2013 at 02:38:27PM -0700, Jeff Davis wrote:
> > In general, we have more flexibility with WAL because there is no
> > upgrade issue. It would be nice to share code with the data page
> > checksum algorithm; but really we should ju
On Fri, Apr 12, 2013 at 02:38:27PM -0700, Jeff Davis wrote:
> In general, we have more flexibility with WAL because there is no
> upgrade issue. It would be nice to share code with the data page
> checksum algorithm; but really we should just use whatever offers the
> best trade-off in terms of com
On Sat, 2013-04-06 at 21:51 +0200, Tomas Vondra wrote:
> This more or less works in stable environments, but once you start
> dropping databases (think of hosting with shared DB server) it gets
> unusable because after DROP DATABASE the database suddenly disappears
> from the sum.
>
> Therefore I
On Sat, 2013-04-06 at 13:20 -0700, Jeff Janes wrote:
> I've often wanted to know what the autovacuum worker was doing. The
> process title seems like the best place to get this information, but
> the process title tells me what database it is in, but not what table
> it is working on.
Because th
On 12 April 2013 23:21, Ants Aasma wrote:
>> In general, we have more flexibility with WAL because there is no
>> upgrade issue. It would be nice to share code with the data page
>> checksum algorithm; but really we should just use whatever offers the
>> best trade-off in terms of complexity, per
15 matches
Mail list logo
