pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Craig A. James <cjames@modgraph-usa.com>
To: pgsql-performance@postgresql.org
Subject: Storage/Performance and splitting a table
Date: Sat, 19 Nov 2005 09:54:23 -0800
Message-ID: <437F66CF.7080402@modgraph-usa.com> (raw)
In-Reply-To: <20051118034631.GA70159@winnie.fuhr.org>
References: <BF9F6C0E.13B4A%llonergan@greenplum.com>
	<1132136225.5711.4.camel@Panoramix>
	<437B9DA9.2030806@modgraph-usa.com>
	<20051117002344.GA55377@winnie.fuhr.org>
	<437CF055.6020602@modgraph-usa.com>
	<20051117232857.GA49910@winnie.fuhr.org>
	<437D3085.9040207@modgraph-usa.com>
	<20051118034631.GA70159@winnie.fuhr.org>

In a recent thread, several people pointed out that UPDATE = DELETE+INSERT.  This got me to wondering.

I have a table that, roughly, looks like this:

  create table doc (
     id         integer primary key,
     document   text,
     keywords   tsvector
   );

where "keywords" has a GIST index.  There are about 10 million rows in the table, and an average of 20 keywords per document.  I have two questions.

First, I occasionally rebuild the keywords, after which the VACUUM FULL ANALYZE takes a LONG time - like 24 hours.  Given the UPDATE = DELETE+INSERT, it sounds like I'd be better off with something like this:

  create table doc (
     id         integer primary key,
     document   text,
   );
  create table keywords (
     id         integer primary key,
     keywords   tsvector
   );

Then I could just drop the GIST index, truncate the keywords table, rebuild the keywords, and reindex.  My suspicion is that VACUUM FULL ANALYZE would be quick -- there would be no garbage to collect, so all it would to do is the ANALYZE part.

My second question: With the doc and keywords split into two tables, would the tsearch2/GIST performance be faster?  The second schema's "keywords" table has just pure keywords (no documents); does that translate to fewer blocks being read during a tsearch2/GIST query?  Or are the "document" and "keywords" columns of the first schema already stored separately on disk so that the size of the "document" data doesn't affect the "keywords" search performance?

Thanks,
Craig



view thread (2+ messages)  latest in thread

Message-ID: <437F66CF.7080402@modgraph-usa.com>
Permalink:  ../437F66CF.7080402@modgraph-usa.com/
Also on:    postgresql.org/message-id/437F66CF.7080402@modgraph-usa.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: cjames@modgraph-usa.com
  Subject: Re: Storage/Performance and splitting a table
  In-Reply-To: <437F66CF.7080402@modgraph-usa.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