pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Shaun Thomas <sthomas@peak6.com>
To: felix <crucialfelix@gmail.com>
Cc: Scott Marlowe <scott.marlowe@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Really really slow select count(*)
Date: Fri, 4 Feb 2011 14:37:56 -0600
Message-ID: <4D4C63A4.6090109@peak6.com> (raw)
In-Reply-To: <AANLkTimw2izMi4QfizQm72ABePackWXhhUU9EHdNf3zk@mail.gmail.com>
References: <AANLkTinAJcm5A+i1O_R87aiYyu8N2OWgoaL9RfR=tUR9@mail.gmail.com>
	<4D4C138C.7010304@2ndquadrant.com>
	<4D4C1555.40209@peak6.com>
	<AANLkTikrS5JkJDMjAXpcRWRnuLbX+MHB=CWb_mFa9qb-@mail.gmail.com>
	<4D4C2AC3.5020804@peak6.com>
	<AANLkTikN75hcCL5Nhgh8Z9c7ZLtduMdjsn07BgO_D_yZ@mail.gmail.com>
	<AANLkTikpH2ws_iiyqNE-o-TWB0-5pMbrS0V5SymXBo2X@mail.gmail.com>
	<AANLkTi=3n_W-OFVuVHx3Tthn_KiMN42BturJUS5BuWVz@mail.gmail.com>
	<4D4C3BCA.5010808@peak6.com>
	<AANLkTikjw46g=VD5vbkOfDz93JMX7vBijj7dTEs+LN4U@mail.gmail.com>
	<4D4C46C2.1080108@peak6.com>
	<AANLkTi=JC_qesUkZNZBRHVRtRZjR3JwSv9L7fLdskU-8@mail.gmail.com>
	<AANLkTi=PsJkYJq1+-4a6OjOQOm3qaOn-HUz0VEdOv4LU@mail.gmail.com>
	<AANLkTim+s+LcLWWjsf1cToPiDrrLxwO30PdN_3=U=7JO@mail.gmail.com>
	<4D4C5AE6.4030101@peak6.com>
	<AANLkTimw2izMi4QfizQm72ABePackWXhhUU9EHdNf3zk@mail.gmail.com>

On 02/04/2011 02:14 PM, felix wrote:

> oh and there in the footnotes to django they say "dont' forget to run
> the delete expired sessions management every once in a while".
> thanks guys.

Oh Django... :)

> it won't run now because its too big, I can delete them from psql though

You might be better off deleting the inverse. You know, start a 
transaction, select all the sessions that *aren't* expired, truncate the 
table, insert them back into the session table, and commit.

BEGIN;
CREATE TEMP TABLE foo_1 AS
SELECT * FROM django_session WHERE date_expired < CURRENT_DATE;
TRUNCATE django_session;
INSERT INTO django_session SELECT * from foo_1;
COMMIT;

Except I don't actually know what the expired column is. You can figure 
that out pretty quick, I assume. That'll also have the benefit of 
cleaning up the indexes and the table all at once. If you just do a 
delete, the table won't change at all, except that it'll have less 
active records.

> well just think how sprightly my website will run tomorrow once I fix
> these.

Maybe. :)

-- 
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas@peak6.com

______________________________________________

See  http://www.peak6.com/email_disclaimer.php
for terms and conditions related to this email



view thread (66+ messages)  latest in thread

Message-ID: <4D4C63A4.6090109@peak6.com>
Permalink:  ../4D4C63A4.6090109@peak6.com/
Also on:    postgresql.org/message-id/4D4C63A4.6090109@peak6.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: sthomas@peak6.com, crucialfelix@gmail.com, scott.marlowe@gmail.com
  Subject: Re: Really really slow select count(*)
  In-Reply-To: <4D4C63A4.6090109@peak6.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox