On Monday 20 July 2015 12:42:47 Federico Capoano wrote:
>
> Just a final note: I think this solution is not the optimal one
I agree. The optimal solution would be for us to be able to define a test
database with unlogged tables and all the data-integrity-sync options off,
while the "production"
I just changed the URL in the to
http://www.postgresql.org/docs/current/static/non-durability.html as
suggested.
Federico
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and
The doc building process includes a linkchecker, if the link ceases to
exist we will get notified (so the worst thing could be that the content
changes to something completely different).
On Tuesday, July 21, 2015 at 8:46:29 AM UTC+2, Christian Schmitt wrote:
>
> I mean I made the proposal, but
I mean I made the proposal, but one drawback will be when linking to
Postgresql Docs, what if they change the links? I mean that's barely
happend in the past, however the "
http://www.postgresql.org/docs/current/static/non-durability.html"; is
fairly new. (9.x).
So we need to track every major upgr
I made a small comment about the URL form. To my ear, the text could use a bit
of wordsmithing, but I think it's the right content.
On Jul 20, 2015, at 3:10 AM, Federico Capoano
wrote:
> Errata, PR link is https://github.com/django/django/pull/5021 - sorry
>
> On Mon, Jul 20, 2015 at 11:42 A
Errata, PR link is https://github.com/django/django/pull/5021 - sorry
On Mon, Jul 20, 2015 at 11:42 AM, Federico Capoano
wrote:
> Thank you for all the feedback.
>
> I opened this PR with the proposed addition to the docs:
> https://github.com/django/django/compare/master...nemesisdesign:patch-1
Thank you for all the feedback.
I opened this PR with the proposed addition to the docs:
https://github.com/django/django/compare/master...nemesisdesign:patch-1
Let me know if there's anything I can improve.
Just a final note: I think this solution is not the optimal one, let
me explain you why.
I second what Aymeric say rather than take on the burden of
maintaining correct warnings, let's point at the people whose
responsibility it really is :)
--
Curtis
On 20 July 2015 at 06:44, Aymeric Augustin
wrote:
> I agree with pointing to the relevant section of the PostgreSQL
> documentat
I agree with pointing to the relevant section of the PostgreSQL documentation.
It will always be more complete, accurate and up-to-date that what we could
write.
--
Aymeric.
> On 19 juil. 2015, at 19:43, Christophe Pettus wrote:
>
> This can be achieved by pointing to the relevant section
This can be achieved by pointing to the relevant section in the PostgreSQL
documentation with a general "Test execution may be sped up by adjusting the
data integrity parameters in PostgreSQL; be sure to read the appropriate
warnings before making any changes" warning.
Putting actual recommende
I agree with Federico on this - as long as we slap a big warning on it —
"This is dangerous - it could make your database more likely to lose
data or become corrupted, only use on a development machine where you
can restore the entire contents of all databases in the cluster easily"
— I don't s
On Jul 16, 2015, at 1:16 AM, Federico Capoano
wrote:
> I also don't like the idea of believing django users are too stupid to
> understand that this advice si valid for development only. Generally
> python and django users are intelligent enough to properly read the
> docs and understand what's
Hey Christophe,
On Thu, Jul 16, 2015 at 8:34 AM, Christophe Pettus wrote:
[CUT]
>
> By the way, I would strongly advise *against* *ever* even mentioning fsync =
> off anywhere in the Django documentation; that is such a horribly bad idea in
> 99.95% of real-life situations that steering people
On Jul 15, 2015, at 8:35 PM, Curtis Maloney wrote:
> On 16 July 2015 at 05:01, Shai Berger wrote:
>> This is a shot in the dark: Could it be that rolling back transactions
>> involving unlogged tables is harder? The idea does make sense, and running
>> the
>> test suite does an extremely untyp
On 16 July 2015 at 05:01, Shai Berger wrote:
> This is a shot in the dark: Could it be that rolling back transactions
> involving unlogged tables is harder? The idea does make sense, and running the
> test suite does an extremely untypical amount of rollbacks.
I thought at some point I read that
This is a shot in the dark: Could it be that rolling back transactions
involving unlogged tables is harder? The idea does make sense, and running the
test suite does an extremely untypical amount of rollbacks.
On Wednesday 15 July 2015 16:19:47 Federico Capoano wrote:
> That's quite baffling.
>
That's quite baffling.
On Tuesday, July 14, 2015 at 7:03:03 PM UTC+2, Tim Graham wrote:
>
> I see a thirty second increase in the test suite (from 7.5 minutes to 8
> minutes) on my local machine with:
>
> sql_create_table = "CREATE UNLOGGED TABLE %(table)s (%(definition)s)"
>
--
You received t
I see a thirty second increase in the test suite (from 7.5 minutes to 8
minutes) on my local machine with:
sql_create_table = "CREATE UNLOGGED TABLE %(table)s (%(definition)s)"
On Tuesday, July 14, 2015 at 4:20:45 AM UTC-4, Federico Capoano wrote:
>
> That's also a viable alternative, although i
That's also a viable alternative, although it also mention unlogged tables,
which are not supported by django.
We could list the quick hint with config sample, a link to pg non durable
options page and a warning that UNLOGGED tables are not supported yet. What
do you think about this?
BTW has any
Wouldn't it be enough to just have link to the correct PostgreSQL site:
http://www.postgresql.org/docs/current/static/non-durability.html
And then some text with "if you want to run your tests on postgresql please
see the docs around non durable postgres"
2015-07-13 18:46 GMT+02:00 Federico Capoan
Sure, i've just done something similar for this project:
http://nodeshot.readthedocs.org/en/latest/topics/install_development.html#how-to-setup-the-test-environment
The *keepdb* option allows to avoid recreating the test database at each
run, hence saving precious time.
If you want to speed up t
Hello Federico,
2015-07-13 16:26 GMT+02:00 Federico Capoano :
> While these are the winners:
>
>- fsync = off
>- synchronous_commit = off
>- full_page_writes = off
>
> Would you like to submit a patch to docs/ref/databases.txt, in the
"PostgreSQL
notes" section, explaining this config
>From http://www.postgresql.org/docs/9.4/static/sql-createtable.html
UNLOGGED
If specified, the table is created as an unlogged table. Data
written to unlogged tables is not written to the write-ahead log (see
Chapter 29), which makes them considerably faster than ordinary
tables. However
I just ran into this ticket:
https://code.djangoproject.com/ticket/24306
I found myself in a situation where it would be really useful.
Two questions:
- has anybody verified that UNLOGGED tables really perform faster when
running tests with Postgres?
- is this feature on the TODO list
24 matches
Mail list logo
