On Sat, May 15, 2010 at 10:20 PM, Peter Eisentraut wrote:
> You have null bytes in the data value, which is not supported very well
> in PL/Python. Try the 9.0 beta version; it should be fixed there.
Thanks. Out of curiosity, is this an issue just with PL/Python or with
other stored procedure la
On lör, 2010-05-15 at 15:40 -0700, Yang Zhang wrote:
> yang=# select * from qapb;
> id | pb
> +
> 0 | \012\006hello?\020\000\030\000 \000*\014\012\006hello!\020\000\030\000
> (1 row)
>
On May 15, 2010, at 8:00 PM, Tom Lane wrote:
Tom Duffey writes:
On May 15, 2010, at 7:28 PM, Tom Lane wrote:
Well, I tried executing a large "copy (select ...)" query and
couldn't
see any memory bloat at all in either the backend or psql. So
there's
something relevant that you haven't t
Tom Duffey writes:
> On May 15, 2010, at 7:28 PM, Tom Lane wrote:
>> Well, I tried executing a large "copy (select ...)" query and couldn't
>> see any memory bloat at all in either the backend or psql. So there's
>> something relevant that you haven't told us.
> I hope you are right! The actual
On May 15, 2010, at 7:28 PM, Tom Lane wrote:
Tom Duffey writes:
On May 15, 2010, at 4:51 PM, Tom Lane wrote:
What's being done on the client side with the data?
I am executing the query in psql at the command line and piping the
result to a file, e.g.,
psql < get_data.sql > data.sql
Wel
Tom Duffey writes:
> On May 15, 2010, at 4:51 PM, Tom Lane wrote:
>> What's being done on the client side with the data?
> I am executing the query in psql at the command line and piping the
> result to a file, e.g.,
> psql < get_data.sql > data.sql
Well, I tried executing a large "copy (selec
On May 15, 2010, at 4:51 PM, Tom Lane wrote:
Tom Duffey writes:
I have a table with several hundred million rows of timestamped
values. Using pg_dump we are able to dump the entire table to disk
no
problem. However, I would like to retrieve a large subset of data
from this table using so
I have seen something like
INSERT INTO TABLE... ASYNC... long time ago
I mean I want to insert async ly with psql command. I do not want to use
libpq's async interface api.
For one transaction, I want to insert in async way... Is there SET variable
usable within transaction?
Thanks.
I have a table containing a protocol buffer (pb) attribute, and a
stored procedure foo that tries to parse it and return the parsed
value as a human-friendly string (not actual application code, just a
minimal test case to demonstrate the problem). But running foo gives
me nothing back.
yang=# \d
Tom Duffey writes:
> I have a table with several hundred million rows of timestamped
> values. Using pg_dump we are able to dump the entire table to disk no
> problem. However, I would like to retrieve a large subset of data
> from this table using something like:
> COPY (SELECT * FROM hi
sunpeng writes:
> hi,i have this table:
> CREATE TABLE pois(
>uid integer not null,
>name VARCHAR(128),
>catcode VARCHAR(32) not null,
>catname VARCHAR(32),
>others VARCHAR(32)
> );
> SELECT AddGeometryColumn('pois', 'location', 4214, 'POINT', 2);
> and then in my codes,i use
Tom Duffey wrote:
> Hi Everyone,
>
> I have a table with several hundred million rows of timestamped
> values. Using pg_dump we are able to dump the entire table to disk no
> problem. However, I would like to retrieve a large subset of data
> from this table using something like:
>
> COPY (SELECT
Hi Everyone,
I have a table with several hundred million rows of timestamped
values. Using pg_dump we are able to dump the entire table to disk no
problem. However, I would like to retrieve a large subset of data
from this table using something like:
COPY (SELECT * FROM history WHERE ti
hi,i have this table:
CREATE TABLE pois(
uid integer not null,
name VARCHAR(128),
catcode VARCHAR(32) not null,
catname VARCHAR(32),
others VARCHAR(32)
);
SELECT AddGeometryColumn('pois', 'location', 4214, 'POINT', 2);
and then in my codes,i use this invoke to get location column i
Thanks a lot for the patience and help. It worked.
Ivan
> To: i@live.com
> CC: klep...@svana.org; dal...@solfertje.student.utwente.nl;
> pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Persistence problem
> Date: Fri, 14 May 2010 18:34:14 -0400
> From: t...@sss.pgh.pa.us
>
> "I. B
hi,i have this table:
CREATE TABLE pois(
uid integer not null,
name VARCHAR(128),
catcode VARCHAR(32) not null,
catname VARCHAR(32),
others VARCHAR(32)
);
SELECT AddGeometryColumn('pois', 'location', 4214, 'POINT', 2);
and then in my codes,i use this invoke to get location column i
Tom Lane wrote:
> Julian Mehnle writes:
> > Can anyone confirm that --variable command-line options are evaluated
> > before .psqlrc is read and executed? If so, does anyone know the
> > rationale for that? It seems counterintuitive to me, as it makes
> > overriding variables from the command-l
It strongly depends from the queries. Usually yes
Il giorno 2010 5 15 16:20, "Armand Turpel" ha scritto:
Hi,
Does it make sense to create indexes on a table which only contains bigint
fields? Is there any performance gain?
Example:
Table x_rel
id_a bigint
id_b bigint
id_c bigint
id_d bigint
T
Hi,
Does it make sense to create indexes on a table which only contains
bigint fields? Is there any performance gain?
Example:
Table x_rel
id_a bigint
id_b bigint
id_c bigint
id_d bigint
Thanks for replying,
Armand
#
19 matches
Mail list logo
