On Apr 22, 2009, at 8:04 AM, Thomas Finneid wrote:
Alvaro Herrera wrote:
Try TRUNCATE. That leaves the less garbage behind and takes the less
time.
A follow up question, as far as I understand it, delete removes
entries in the fsm, so vacuum has to clean it all up when performing
a delet
Alvaro Herrera wrote:
Try TRUNCATE. That leaves the less garbage behind and takes the less
time.
A follow up question, as far as I understand it, delete removes entries
in the fsm, so vacuum has to clean it all up when performing a delete,
is this approximately correct? what happens with tru
On Tue, 2009-04-21 at 14:30 -0700, Christophe wrote:
> Indeed so, and I understand that part. But since Session1 didn't try
> to access 'bar', it can't distinguish that sequence from:
>
> Session2:
> BEGIN;
> TRUNCATE bar;
> COMMIT;
>
> Session1:
> BEGIN TRANSACTION ISOLATION LEVEL SER
Christophe writes:
> On Apr 21, 2009, at 2:15 PM, Jeff Davis wrote:
>> In Session1, the serializable transaction sees an empty version of
>> bar, even though it had tuples in at the time Session1 got its serializable
>> snapshot.
> Indeed so, and I understand that part. But since Session1 didn
On 21 Kwi, 21:30, alvhe...@commandprompt.com (Alvaro Herrera) wrote:
> marek.patr...@gmail.com escribió:
>
> > I was wondering if dropping a table is more efficient in PostgreSQL
> > 8.x in comparison to deleting it's content ?
>
> "8.x" is a meaningless version number in Postgres. Major versions
Jeff Davis writes:
> On Tue, 2009-04-21 at 13:59 -0700, Christophe wrote:
>> I'm sure there is a scenario under which a separate
>> transaction could see non-MVCC behavior from TRUNCATE, but I'm
>> having trouble see what it is.
> Session1:
> BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
>
On Apr 21, 2009, at 2:15 PM, Jeff Davis wrote:
In Session1, the serializable transaction sees an empty version of
bar,
even though it had tuples in at the time Session1 got its serializable
snapshot.
Indeed so, and I understand that part. But since Session1 didn't try
to access 'bar', it
On Tue, 2009-04-21 at 13:59 -0700, Christophe wrote:
> I'm sure there is a scenario under which a separate
> transaction could see non-MVCC behavior from TRUNCATE, but I'm
> having
> trouble see what it is.
Session1:
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SELECT * FROM foo;
Sessi
On Apr 21, 2009, at 1:36 PM, Tom Lane wrote:
I was thinking of MVCC semantics, which is a different issue.
Indeed so, my error. This is a bit of a drift off-topic, but
rereading the docs, I'm now having trouble visualizing the real-world
effect of the non-MVCC-safeness of TRUNCATE. A tra
x...@thebuild.com (Christophe) writes:
> On Apr 21, 2009, at 12:28 PM, Peter Eisentraut wrote:
>> Yes, but if you are asking that question, you probably really want
>> to use
>> TRUNCATE.
>
> The advantage of DROP TABLE being, of course, that DROP TABLE is
> transactionally-safe, while TRUNCATE is
Christophe writes:
> On Apr 21, 2009, at 1:20 PM, Tom Lane wrote:
>> They're both going to drop data that
>> might conceivably be visible in the snapshot of some concurrent
>> transaction that hasn't yet touched the table (else it would have
>> lock)
>> but might wish to do so later.
> Unless I
On Apr 21, 2009, at 1:20 PM, Tom Lane wrote:
They're both going to drop data that
might conceivably be visible in the snapshot of some concurrent
transaction that hasn't yet touched the table (else it would have
lock)
but might wish to do so later.
Unless I'm deeply misunderstanding somethi
Christophe writes:
> On Apr 21, 2009, at 12:28 PM, Peter Eisentraut wrote:
>> Yes, but if you are asking that question, you probably really want
>> to use TRUNCATE.
> The advantage of DROP TABLE being, of course, that DROP TABLE is
> transactionally-safe, while TRUNCATE is not.
The above is
marek.patr...@gmail.com escribió:
> I was wondering if dropping a table is more efficient in PostgreSQL
> 8.x in comparison to deleting it's content ?
"8.x" is a meaningless version number in Postgres. Major versions (with
new features, etc) are labeled by the first two elements, so 8.0, 8.1,
and
On Apr 21, 2009, at 12:28 PM, Peter Eisentraut wrote:
Yes, but if you are asking that question, you probably really want
to use
TRUNCATE.
The advantage of DROP TABLE being, of course, that DROP TABLE is
transactionally-safe, while TRUNCATE is not.
--
Sent via pgsql-general mailing list (
On Tuesday 21 April 2009 20:26:24 marek.patr...@gmail.com wrote:
> I was wondering if dropping a table is more efficient in PostgreSQL
> 8.x in comparison to deleting it's content ?
Yes, but if you are asking that question, you probably really want to use
TRUNCATE.
--
Sent via pgsql-general ma
I was wondering if dropping a table is more efficient in PostgreSQL
8.x in comparison to deleting it's content ?
To put you in the picture - I want to schedule via cron job some daily
data materialization. With the resource I got there are only those two
ways:
1) DROP statement:
a) DROP TABLE tmp
17 matches
Mail list logo
