On Thu, Jul 12, 2012 at 4:21 PM, Harold A. Giménez
wrote:
> Hi,
>
> I work with Daniel Farina and was the other engineer who "discovered" this,
> once again. That is, I got bit by it and have been running TRUNCATE on my
> test suites for years.
Hi Daniel and Harold,
I don't know if you followed
On Thu, Jul 12, 2012 at 4:21 PM, Harold A. Giménez
wrote:
>
> > What is shared_buffers?
>
>
> 1600kB
That is really small, so the buffer flushing should not be a problem.
Unless you mean 1600MB.
> > > This is a rather small schema -- probably a half a dozen tables, and
> > > probably about a do
Hi,
I work with Daniel Farina and was the other engineer who "discovered" this,
once again. That is, I got bit by it and have been running TRUNCATE on my test
suites for years.
On Thursday, July 12, 2012 at 12:15 PM, Jeff Janes wrote:
> On Wed, Jul 11, 2012 at 3:51 PM, Daniel Farina (mailt
On Wed, Jul 11, 2012 at 3:51 PM, Daniel Farina wrote:
>
> Nope. I don't. But an exact crossover is a level of precision I don't
> really need, because here are where things stand on a completely
> unremarkable test suite on the closest project to me that meets the
> "regular web-app" profile case
On 07/12/2012 02:12 PM, Daniel Farina wrote:
On Wed, Jul 11, 2012 at 6:41 PM, Craig Ringer wrote:
On 07/12/2012 06:51 AM, Daniel Farina wrote:
15x slower. This is a Macbook Air with full disk encryption and SSD
disk with fsync off, e.g. a very typical developer configuration.
Don't use full
On Wed, Jul 11, 2012 at 6:41 PM, Craig Ringer wrote:
> On 07/12/2012 06:51 AM, Daniel Farina wrote:
>>
>> 15x slower. This is a Macbook Air with full disk encryption and SSD
>> disk with fsync off, e.g. a very typical developer configuration.
>
> Don't use full disk encryption for throwaway test
On 07/12/2012 06:51 AM, Daniel Farina wrote:
15x slower. This is a Macbook Air with full disk encryption and SSD
disk with fsync off, e.g. a very typical developer configuration.
Don't use full disk encryption for throwaway test data if you care about
how long those tests take. It's a lot like
On 07/11/2012 01:22 PM, Daniel Farina wrote:
On Tue, Jul 10, 2012 at 5:37 PM, Craig Ringer wrote:
Hi
After seeing a few discussions here and on Stack Overflow I've put together
a quick explanation of why "DELETE FROM table;" may be faster than "TRUNCATE
table" for people doing unit testing on
On 07/12/2012 02:10 AM, Matthew Woodcraft wrote:
I think a documentation change would be worthwhile. At the moment the
TRUNCATE page says, with no caveats, that it is faster than
unqualified DELETE.
+1 to updating the docs to reflect the fact that TRUNCATE may have a
higher fixed cost than D
On Wed, Jul 11, 2012 at 7:05 AM, Tom Lane wrote:
> Daniel Farina writes:
>> TRUNCATE should simply be very nearly the fastest way to remove data
>> from a table while retaining its type information, and if that means
>> doing DELETE without triggers when the table is small, then it should.
>> Th
On Wed, Jul 11, 2012 at 2:32 PM, Mark Thornton wrote:
> On 11/07/12 21:18, Craig James wrote:
>
>>
>> It strikes me as a contrived case rather than a use case. What sort of
>> app repeatedly fills and truncates a small table thousands of times ...
>> other than a test app to see whether you can
On 11/07/12 21:18, Craig James wrote:
It strikes me as a contrived case rather than a use case. What sort
of app repeatedly fills and truncates a small table thousands of times
... other than a test app to see whether you can do it or not?
If I have a lot of data which updates/inserts an exis
On 07/11/2012 04:47 PM, Shaun Thomas wrote:
On 07/11/2012 03:18 PM, Craig James wrote:
It strikes me as a contrived case rather than a use case. What sort of
app repeatedly fills and truncates a small table thousands of times ...
other than a test app to see whether you can do it or not?
Te
On 07/11/2012 03:18 PM, Craig James wrote:
It strikes me as a contrived case rather than a use case. What sort of
app repeatedly fills and truncates a small table thousands of times ...
other than a test app to see whether you can do it or not?
Test systems. Any company with even a medium-siz
On Wed, Jul 11, 2012 at 7:05 AM, Tom Lane wrote:
> Daniel Farina writes:
> > TRUNCATE should simply be very nearly the fastest way to remove data
> > from a table while retaining its type information, and if that means
> > doing DELETE without triggers when the table is small, then it should.
>
Tom Lane wrote:
> (3) The performance of the truncation itself should not be viewed in
> isolation; subsequent behavior also needs to be considered. An example
> of possible degradation is that index bloat would no longer be
> guaranteed to be cleaned up over a series of repeated truncations.
> (Y
On Wed, Jul 11, 2012 at 10:05:48AM -0400, Tom Lane wrote:
> Daniel Farina writes:
> > TRUNCATE should simply be very nearly the fastest way to remove data
> > from a table while retaining its type information, and if that means
> > doing DELETE without triggers when the table is small, then it sho
Daniel Farina writes:
> TRUNCATE should simply be very nearly the fastest way to remove data
> from a table while retaining its type information, and if that means
> doing DELETE without triggers when the table is small, then it should.
> The only person who could thwart me is someone who badly w
On Tue, Jul 10, 2012 at 5:37 PM, Craig Ringer wrote:
> Hi
>
> After seeing a few discussions here and on Stack Overflow I've put together
> a quick explanation of why "DELETE FROM table;" may be faster than "TRUNCATE
> table" for people doing unit testing on lots of tiny tables, people who're
> do
19 matches
Mail list logo
