When Postmaster starts, I've forked another process AP just as syslogger,
bgwritter,...
In the process AP, If I can't find a table, I would create one, the codes
are:
char * sqlCreate_DM_ = "create table DM_( ...); ";
SPI_connect();
int ret = SPI_ex
Thanks for your help!The motivation is that I try to find the most used sub
plan ,and cach the sub plan's execution result and store sub plan itself on
disk. Even the sub plan's connection is closed, the consequent connection
with the same sub plan could utilize the stored cached result.
For examp
sunpeng writes:
> I've used the following codes to translate the PlannedStmt node to a char
> string:
> PlannedStmt * pltl = (PlannedStmt *) linitial(plantree_list);
> Plan *pl = pltl->planTree;
> char *s;
> s = nodeToString(pl);
> How to restore from this s to Plan?
You can't. The fact
I've used the following codes to translate the PlannedStmt node to a char
string:
PlannedStmt * pltl = (PlannedStmt *) linitial(plantree_list);
Plan *pl = pltl->planTree;
char *s;
s = nodeToString(pl);
How to restore from this s to Plan?
I noticed using func parseNodeString() in /backends/
On Fri, Sep 3, 2010 at 3:47 PM, John Adams wrote:
>> psql has some client side manged variables, and you can of course use
>> pl/pgsql.
> Do you mean I should use a pl/pgsql stored procedure or do I have to somehow
> mark the sql as pl/pgsql? How?
> Because in sql server it is all the same i.e. pl
Josh Kupershmidt writes:
> On Fri, Sep 3, 2010 at 4:01 PM, Tom Lane wrote:
>> Interesting. I can't imagine how you could have produced these with
>> plain COPY, since that would go through timestamptzin. Was it by any
>> chance a binary COPY? If so I could believe that funny timestamps could
>
On Fri, Sep 3, 2010 at 4:01 PM, Tom Lane wrote:
> Interesting. I can't imagine how you could have produced these with
> plain COPY, since that would go through timestamptzin. Was it by any
> chance a binary COPY? If so I could believe that funny timestamps could
> get in. Maybe some confusion
Josh Kupershmidt writes:
> On Fri, Sep 3, 2010 at 3:40 PM, Tom Lane wrote:
>> but I wonder what it was you actually did.
> I wonder myself :-) I encountered these timestamps while going through
> some C code I inherited which uses libpq to load several tables (such
> as myschema.strange_table in
On Fri, Sep 3, 2010 at 3:40 PM, Tom Lane wrote:
> Wow. You must have gotten those with the help of some arithmetic,
> because timestamptzin would never have produced them. I found out I can
> do
>
> regression=# select extract(epoch from ('2000-01-01 00:00:00'::timestamptz +
> '0.00
Josh Kupershmidt writes:
> EXTRACT(epoch ...) was what I was looking for:
> SELECT EXTRACT(epoch FROM ts - '1999-12-31 19:00:00-05'::timestamptz)
> FROM timestamps_test LIMIT 5;
>date_part
> ---
> 1.4120666068199e-309
> 1.4154982781624e-309
> 1.41550281692099e-309
[ trivia warning ]
I wrote:
> We don't make any great effort to expose that though. It looks like
> the closest value that timestamptzin makes different from zero is
> regression=# select extract(epoch from '1999-12-31 19:00:00.001-05' -
> '1999-12-31 19:00:00-05'::timestamptz) ;
>
On Fri, Sep 3, 2010 at 3:24 PM, Tom Lane wrote:
> regression=# select extract(epoch from ts - '1999-12-31
> 19:00:00-05'::timestamptz) from t1;
> date_part
> --
> 1.0761449337e-07
> 0
> (2 rows)
>
> This timestamp (2000-01-01 00:00 GMT) is actually
On Fri, Sep 3, 2010 at 2:45 PM, John Adams wrote:
> How can I use parameters in plain sql like sql server.
>
> FICTIONAL example that works for sql server:
> declare @i int;
> set @i = 1;
> select * from mytable where i...@i;
postgresql doesn't support variables in plain sql. psql has some
clien
Josh Kupershmidt writes:
> On Fri, Sep 3, 2010 at 2:58 PM, Tom Lane wrote:
>> I'm thinking some of them might be different by submicrosecond amounts.
> Ah yes, this is likely why. pg_config says CONFIGURE = ...
> '--disable-integer-datetimes' ...
> But I'm having trouble seeing for sure whether
How can I use parameters in plain sql like sql server.
FICTIONAL example that works for sql server:
declare @i int;
set @i = 1;
select * from mytable where i...@i;
On Fri, Sep 3, 2010 at 2:58 PM, Tom Lane wrote:
> Is this installation using float or integer timestamps? If the former,
> it might be interesting to look at the subtraction result
> ts - '1999-12-31 19:00:00-05'::timestamptz
> I'm thinking some of them might be different by submicrosecond
Josh Kupershmidt writes:
> I've come across a puzzling situation with a table having a timestamp
> with time zone column. This column is full of values displaying
> exactly as '1999-12-31 19:00:00-05', but for some reason Postgres is
> treating some of these identical-seeming timestamps as being
>
Hi all,
I've come across a puzzling situation with a table having a timestamp
with time zone column. This column is full of values displaying
exactly as '1999-12-31 19:00:00-05', but for some reason Postgres is
treating some of these identical-seeming timestamps as being
different.
If I update al
- Original Message -
From: "Craig Ringer"
To: "Bayless Kirtley"
Cc: "List, Postgres"
Sent: Thursday, September 02, 2010 10:15 PM
Subject: Re: [GENERAL] Connection question
On 2/09/2010 11:59 PM, Bayless Kirtley wrote:
Thanks a lot Craig. The register is connecting through localho
> Date: Fri, 3 Sep 2010 09:41:17 +0200
> Subject: Re: [GENERAL] Compiling extension C with MingW in windows, Error...
> From: mag...@hagander.net
> To: listas_quij...@hotmail.com
> CC: pgsql-general@postgresql.org
>
> On Fri, Sep 3, 2010 at 5:31 AM, Edwin Quijada
> wrote:
> > Hi, I am tryng
In response to Steve Clark :
> >Try this with explicet cast:
>
> Thanks guys, that seems to do the trick. Postgresql ROCKS!!!
Yeah, definitively!
You are welcome, Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG: 0x31720C99, 1006 CCB4 A32
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes:
> On Fri, 2010-09-03 at 09:41 -0400, Tom Lane wrote:
>>> This is 8.4.4 btw...
>>
>> OK, so the bug is fixed, but you still have fillfactor = 0 on the
>> affected table.
> I'm confused. I'm still seeing a bug in here: I cannot restore a dump
> effectivel
On Fri, 2010-09-03 at 09:41 -0400, Tom Lane wrote:
> > This is 8.4.4 btw...
>
> OK, so the bug is fixed, but you still have fillfactor = 0 on the
> affected table.
I'm confused. I'm still seeing a bug in here: I cannot restore a dump
effectively... Running CLUSTER or VACUUM FULL does not make any
On 09/03/2010 09:38 AM, A. Kretschmer wrote:
In response to Steve Clark :
Hello List,
I want to change some columns in a database
that were originally created as char varying to
inet.
When I try I get an error. Is there anyway to work
around this?
See below for table definition.
Hi everyone.
I am using Postgres 8.4.4 on a large-ish amount of data and recently noticed
that my application got very slow at times. I quickly discovered that a
specific query was triggering a sequential scan despite suitable indices
being available. The query in question looks like this:
"sel
Hi everyone.
I am using Postgres 8.4.4 on a large-ish amount of data and recently noticed
that my application got very slow at times. I quickly discovered that a
specific query was triggering a sequential scan despite suitable indices
being available. The query in question looks like this:
"select
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes:
> On Thu, 2010-09-02 at 13:22 -0400, Tom Lane wrote:
>> Devrim, have you identified yet which tables have the bloat? Are they
>> the ones with tweaked autovacuum parameters?
> That's it.
> On prod server, that table consumes 50 GB disk space, and on t
In response to Steve Clark :
> Hello List,
>
> I want to change some columns in a database
> that were originally created as char varying to
> inet.
>
> When I try I get an error. Is there anyway to work
> around this?
>
> See below for table definition.
>
> Table "public.kernel
On Fri, Sep 3, 2010 at 7:21 AM, Steve Clark wrote:
> Hello List,
>
> I want to change some columns in a database
> that were originally created as char varying to
> inet.
>
> When I try I get an error. Is there anyway to work
> around this?
>
> See below for table definition.
>
> Ta
Hello List,
I want to change some columns in a database
that were originally created as char varying to
inet.
When I try I get an error. Is there anyway to work
around this?
See below for table definition.
Table "public.kernel_gre"
Column | Type | M
I wonder if there's an equivalent of gcore on windows. If there is, it
might be useful.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, Sep 3, 2010 at 5:31 AM, Edwin Quijada
wrote:
> Hi, I am tryng to compile a C extension in windows using Minigw but always I
> get the same error
>
> C:\Program Files\PostgreSQL\8.3\share\exte_c>C:\mingw\bin\gcc -shared -o
> pg2.dll
> pg2.o
> pg2.o:pg2.c:(.text+0x86): undefined reference t
Henk van Lingen wrote:
Now there are two types of query plans:
syslog=# explain SELECT id, devicereportedtime, facility, priority, fromhost, syslogtag, infounitid, message FROM systemevents WHERE ( ( to_tsvector('english', message) @@ to_tsquery ( '131.211.112.9')) ) ORDER BY id DESC LIMIT 100
33 matches
Mail list logo
