You guys are smart!
Apache was running against an old libpq. I shutdown apache, updated
/etc/ld.so.conf with the postgres lib dir, ran ldconfig, restarted
apache, and the problem went away.
The old libpq was libpq.so.3.0 (pre-installed on machine). The new one
is libpq.so.3.2 (installed wi
On Thu, Feb 09, 2006 at 12:46:46PM -0300, Alvaro Herrera wrote:
> I note in the PHP 4 sources that the PQunescapeBytea function seems to
> have been copied there, "for the benefit of PostgreSQL 7.2 users". It
> says that it comes from 7.3 but I don't see any sscanf call.
>
> There is no PQunescap
Tom Lane wrote:
> Kalador Tech Support <[EMAIL PROTECTED]> writes:
> > When run from a browser, accessing an Apache webserver, the results
> > displayed were:
>
> > fetchtime = 3.632ms, 296043 bytes
> > unescape time = 70625.518ms, 296043 bytes
>
> Is it possible that you are relying on an o
Kalador Tech Support <[EMAIL PROTECTED]> writes:
> When run from a browser, accessing an Apache webserver, the results
> displayed were:
> fetchtime = 3.632ms, 296043 bytes
> unescape time = 70625.518ms, 296043 bytes
Is it possible that you are relying on an old (like 7.3) libpq?
I find this
I modified your code slightly to isolate the pg_unescape_bytea() from
the pg_fetch_result():
When run from a browser, accessing an Apache webserver, the results
displayed were:
fetchtime = 3.632ms, 296043 bytes
unescape time = 70625.518ms, 296043 bytes
When running the same code from c
On Wed, Feb 08, 2006 at 09:52:33AM -0800, Kalador Tech Support wrote:
> $tfetch = microtime(true);
>
> // Convert to binary and send to the browser
> // header('Content-type: image/gif');
> header('Content-type: text/plain');
> $data = pg_unescape_bytea($raw);
> $dt = microtime(true) - $tfetch;
T
On Sat, Feb 04, 2006 at 04:06:11PM -0800, Kalador Tech Support wrote:
> I've since isolated the problem to the unescape_bytea function not the
> SELECT.
>
> I inserted the same image to a bytea column using base64 encoding, and
> extracted it from the table (using base64 decoding) and this worke
This is a table with just one entry created to test the problem. Should
not have any indexing issues.
I've since isolated the problem to the unescape_bytea function not the
SELECT.
I inserted the same image to a bytea column using base64 encoding, and
extracted it from the table (using base
Kai Ronan wrote:
> // Get the bytea data
> $res = pg_query("SELECT data FROM image WHERE name='big.gif'");
Do you have an index in the image.name column? What does an
EXPLAIN ANALYZE SELECT data FROM image WHERE name='big.gif'
say?
--
Alvaro Herrerahttp://w
The following bug has been logged online:
Bug reference: 2236
Logged by: Kai Ronan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: redhat linux
Description:extremely slow to get unescaped bytea data from db
Details:
Using php 5.1.2, tryi
10 matches
Mail list logo
