pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Scott Cain <cain@cshl.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: EXTERNAL storage and substring on long strings
Date: 31 Jul 2003 16:20:39 -0400
Message-ID: <1059682839.5415.53.camel@localhost.localdomain> (raw)
In-Reply-To: <18305.1059680697@sss.pgh.pa.us>
References: <1059679600.1429.41.camel@localhost.localdomain>
	<18305.1059680697@sss.pgh.pa.us>

On Thu, 2003-07-31 at 15:44, Tom Lane wrote:
> Scott Cain <cain@cshl.org> writes:
> > explain analyze select substring(residues from 1000000 for 20000)
> > from feature where feature_id=1;
> 
> > where feature is a table with ~3 million rows, and residues is a text
> > column, where for the majority of the rows of feature, it is null, for a
> > large minority, it is shortish strings (a few thousand characters), and
> > for 6 rows, residues contains very long strings (~20 million characters
> > (it's chromosome DNA sequence from fruit flies)).
> 
> I think the reason uncompressed storage loses here is that the runtime
> is dominated by the shortish strings, and you have to do more I/O to get
> at those if they're uncompressed, negating any advantage from not having
> to fetch all of the longish strings.

I'm not sure I understand what that paragraph means, but it sounds like,
if PG is working the way it is supposed to, tough for me, right?
> 
> Or it could be that there's a bug preventing John Gray's substring-slice
> optimization from getting used.  The only good way to tell that I can
> think of is to rebuild PG with profiling enabled and try to profile the
> execution both ways.  Are you up for that?

I am not against recompiling.  I am currently using an RPM version, but
I could probably recompile; the compilation is probably straight forward
(adding something like `--with_profiling` to ./configure), but how
straight forward is actually doing the profiling?  Is there a document
somewhere that lays it out?
> 
> (BTW, if you are using a multibyte database encoding, then that's your
> problem right there --- the optimization is practically useless unless
> character and byte indexes are the same.)

I shouldn't be, but since it is an RPM, I can't be sure.  It sure would
be silly since the strings consist only of [ATGCN].

Thanks,
Scott

-- 
------------------------------------------------------------------------
Scott Cain, Ph. D.                                         cain@cshl.org
GMOD Coordinator (http://www.gmod.org/)                     216-392-3087
Cold Spring Harbor Laboratory




view thread (31+ messages)  latest in thread

Message-ID: <1059682839.5415.53.camel@localhost.localdomain>
Permalink:  ../1059682839.5415.53.camel@localhost.localdomain/
Also on:    postgresql.org/message-id/1059682839.5415.53.camel@localhost.localdomain

 · 

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-sql@postgresql.org
  Cc: cain@cshl.org, tgl@sss.pgh.pa.us, pgsql-performance@postgresql.org
  Subject: Re: EXTERNAL storage and substring on long strings
  In-Reply-To: <1059682839.5415.53.camel@localhost.localdomain>

* 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