Re: SUBSTRING performance for large BYTEA

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Vance Maverick <vmaverick(at)pgp(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: SUBSTRING performance for large BYTEA
Date: 2007-08-18 16:32:02
Message-ID: 46C71F02.5090307@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Lane wrote:
> "Vance Maverick" <vmaverick(at)pgp(dot)com> writes:
>> My question is about performance in the postgres server. When I execute
>> "SELECT SUBSTRING (my_bytea FROM ? FOR ?) FROM my_table WHERE id =3D ?",
>> does it fetch the whole BYTEA into memory? Or does it access only the
>> pages that contain the requested substring?
>
> Recent releases will do what you want if the column has been marked
> SET STORAGE EXTERNAL (before storing anything in it...) See the
> ALTER TABLE reference page.

Should we consider setting storage external by default for the type?

Joshua D. Drake

>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

- --

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGxx8CATb/zqfZUUQRAkXkAJ4i6GKe7/v8dHOaj8fjTvc2hZZN4wCgknFQ
VVaj655AAbKFipfFNcAbdos=
=jdgD
-----END PGP SIGNATURE-----

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Raymond O'Donnell 2007-08-18 16:36:46 Re: Finding my database
Previous Message ruediger.papke 2007-08-18 16:31:03 waiting in pg_stats_activity