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

help / color / mirror / Atom feed
From: Alvaro Herrera <alvherre@commandprompt.com>
To: David Jarvis <thangalin@gmail.com>
Cc: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: Optimize date query for large child tables: GiST or GIN?
Date: Tue, 01 Jun 2010 15:00:26 -0400
Message-ID: <1275418606-sup-7720@alvh.no-ip.org> (raw)
In-Reply-To: <AANLkTimj8bGLBr4trW8JMYe-HPdV6bjWtB_y79qOquVL@mail.gmail.com>
References: <AANLkTimi_Jh4J6bLZ8lZ0cGQ0VVG7XPCKaFN9GRHd6mP@mail.gmail.com>
	<AANLkTimk7lRS8FHJOot3tF-c6Ds4jexCvWKEQNU1V0Xt@mail.gmail.com>
	<7143.1274382139@sss.pgh.pa.us>
	<AANLkTim7O3Aalp31WKwBuTufYXeUMQWkwy51nvRcI0QY@mail.gmail.com>
	<AANLkTikl8wlHPJaArMWO9XWgG0vk9tununw3eUAYh1IC@mail.gmail.com>
	<7767.1274385170@sss.pgh.pa.us>
	<AANLkTikOEC-Gr3eqGlyGauRAZJknQEaS5DEWw-ZOcl6r@mail.gmail.com>
	<7917.1274385834@sss.pgh.pa.us>
	<AANLkTimLdBWaVpSF5Sc3ArT_9jcAjhNiB9WBBA4HIyXj@mail.gmail.com>
	<8132.1274386738@sss.pgh.pa.us>
	<AANLkTin2REsIs5CTQ7qmBCQHpJqHdhn70iSNNrHq75V5@mail.gmail.com>
	<alpine.DEB.2.00.1006011054270.4083@aragorn.flymine.org>
	<1275412319-sup-2359@alvh.no-ip.org>
	<AANLkTimj8bGLBr4trW8JMYe-HPdV6bjWtB_y79qOquVL@mail.gmail.com>

Excerpts from David Jarvis's message of mar jun 01 14:01:22 -0400 2010:
> Sorry, Alvaro.
> 
> I was contemplating using a GIN or GiST index as a way of optimizing the
> query.

My fault -- I didn't read the whole thread.

> Instead, I found that re-inserting the data in order of station ID (the
> primary look-up column) and then CLUSTER'ing on the station ID, taken date,
> and category index increased the speed by an order of magnitude.

Hmm, that's nice, though I cannot but wonder whether the exclusive lock
required by CLUSTER is going to be a problem in the long run.

> I might be able to drop the station/taken/category index in favour of the
> simple station index and CLUSTER on that, instead (saving plenty of disk
> space). Either way, it's fast right now so I'm not keen to try and make it
> much faster.

Hm, keep in mind that if the station clause alone is not selective
enough, scanning it may be too expensive.  The current three column
index is probably a lot faster to search (though of course it's causing
more work to be kept up to date on insertions).

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support



view thread (44+ messages)  latest in thread

Message-ID: <1275418606-sup-7720@alvh.no-ip.org>
Permalink:  ../1275418606-sup-7720@alvh.no-ip.org/
Also on:    postgresql.org/message-id/1275418606-sup-7720@alvh.no-ip.org

 · 

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: alvherre@commandprompt.com, thangalin@gmail.com
  Subject: Re: Optimize date query for large child tables: GiST or GIN?
  In-Reply-To: <1275418606-sup-7720@alvh.no-ip.org>

* 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