On Jun 1, 2011 1:46 PM, "Jan Hudec" wrote:
> On Tue, May 31, 2011 at 16:44:13 -0500, Nico Williams wrote:
> > On Tue, May 31, 2011 at 4:22 PM, Simon Slavin
wrote:
> > > Split the DROP into two stages:
> > >
> > > DELETE FROM myTable;
> > > DROP TABLE myTable;
> > >
> > > Which one takes all the t
On Tue, May 31, 2011 at 16:44:13 -0500, Nico Williams wrote:
> On Tue, May 31, 2011 at 4:22 PM, Simon Slavin wrote:
> > Split the DROP into two stages:
> >
> > DELETE FROM myTable;
> > DROP TABLE myTable;
> >
> > Which one takes all the time ? If it's the second one, then perhaps just
> > delete
On 06/01/2011 02:18 AM, Jan Hudec wrote:
> Hellow folks,
>
> At $work we have an application that processes *huge* (tens of millions of
> rows in some of the larger tables, sometimes over 30GiB file size). This
> application changes and when it does, it drops some tables and calculates
> them again
>Quoth Roger Binns , on 2011-06-01 00:21:44 -0700:
> > On 05/31/2011 12:18 PM, Jan Hudec wrote:
> > > - Is there any way to speed it up?
> >
> > Another way (somewhat hinted at by Nico) is that you can create
> these tables
> > in separate databases and use attach to bring them in. To drop a
>
Quoth Roger Binns , on 2011-06-01 00:21:44 -0700:
> On 05/31/2011 12:18 PM, Jan Hudec wrote:
> > - Is there any way to speed it up?
>
> Another way (somewhat hinted at by Nico) is that you can create these tables
> in separate databases and use attach to bring them in. To drop a table you
> can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/31/2011 12:18 PM, Jan Hudec wrote:
> - Is there any way to speed it up?
Another way (somewhat hinted at by Nico) is that you can create these tables
in separate databases and use attach to bring them in. To drop a table you
can just detach an
On 31 May 2011, at 10:44pm, Nico Williams wrote:
> You could rename the table and then delete from ... order by rowid asc
> limit 1000, to delete 1000 rows at a time. Add in incremental
> autovacuum and that might do the trick.
Would
DELETE FROM myTable ORDER BY rowid DESC LIMIT 1
be any fast
On Tue, May 31, 2011 at 4:22 PM, Simon Slavin wrote:
> Split the DROP into two stages:
>
> DELETE FROM myTable;
> DROP TABLE myTable;
>
> Which one takes all the time ? If it's the second one, then perhaps just
> delete all the records. Filling the table back up again with new rows
> obviously
On 31 May 2011, at 8:18pm, Jan Hudec wrote:
> At $work we have an application that processes *huge* (tens of millions of
> rows in some of the larger tables, sometimes over 30GiB file size). This
> application changes and when it does, it drops some tables and calculates
> them again. What is som
On Tue, May 31, 2011 at 12:30:59 -0700, Roger Binns wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/31/2011 12:18 PM, Jan Hudec wrote:
> > and calculates them again.
>
> Have you considered using virtual tables so that the calculations are done
> on access as needed rather than
On Tue, May 31, 2011 at 14:29:11 -0500, Nico Williams wrote:
> Just a guess: finding all the pages to free requires traversing the
> internal nodes of the table's b-tree, which requires reading a fair
> subset of the table's b-tree, which might be a lot of I/O. At 150MB/s
> it would take almost tw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/31/2011 12:18 PM, Jan Hudec wrote:
> and calculates them again.
Have you considered using virtual tables so that the calculations are done
on access as needed rather than up front?
Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU
Just a guess: finding all the pages to free requires traversing the
internal nodes of the table's b-tree, which requires reading a fair
subset of the table's b-tree, which might be a lot of I/O. At 150MB/s
it would take almost two minutes to read 15GB of b-tree pages from a
single disk, and that's
Hellow folks,
At $work we have an application that processes *huge* (tens of millions of
rows in some of the larger tables, sometimes over 30GiB file size). This
application changes and when it does, it drops some tables and calculates
them again. What is somewhat surprising is that dropping the t
14 matches
Mail list logo
