Andy Colson-2 wrote:
>
> Can you post an explain analyze'es'es for (1) when its quick and (2)
> when its slow?
>
Here are results:
1. Upon startup:
QUERY
PLAN
On Sat, Oct 03, 2009 at 04:20:59PM +1000, ? wrote:
> Since I also need to consider gego, is this the best way to do it?
I think you need to be clearer about what you're trying to count.
Consider a nestjoin plan where:
- For the inner side it considers 7 paths and throws away 4.
- For the
On Sun, Oct 04, 2009 at 01:44:30AM -0700, tomrevam wrote:
> -> Bitmap Index Scan on session_allocation_info_status_idx
> (cost=0.00..5.28 rows=1 width=0) (actual time=1619.652..1619.652 rows=51025
> loops=1)
>Index Cond: ((status)::text = 'active'::text)
> -> B
Bill Moran wrote:
>
> My apologies, I should have asked for the output of VACUUM VERBOSE on
> the problem table in conjunction with these settings. (make sure you
> do VACUUM VERBOSE when the table is exhibiting the speed problem)
>
INFO: vacuuming "public.session_allocation_info"
INFO: sc
Withing PG procedures at least in pgsql it is impossible to do 'money'
calculations
without a loss of precision.
There is an open source library by IBM that I use in my C++ code to do
this, and may be it can
be incorporated into PG
it is called decNumber
http://speleotrove.com/decimal/decnumber.
Sam Mason writes:
> On Sun, Oct 04, 2009 at 01:44:30AM -0700, tomrevam wrote:
>> -> Bitmap Index Scan on session_allocation_info_status_idx (cost=0.00..5.28
>> rows=1 width=0) (actual time=1619.652..1619.652 rows=51025 loops=1)
>> Index Cond: ((status)::text = 'active'::text)
>> -> Bitmap Index
tomrevam writes:
> Bill Moran wrote:
>> My apologies, I should have asked for the output of VACUUM VERBOSE on
>> the problem table in conjunction with these settings. (make sure you
>> do VACUUM VERBOSE when the table is exhibiting the speed problem)
> INFO: "session_allocation_info": found 388
On Sun, Oct 04, 2009 at 11:08:01AM -0400, Tom Lane wrote:
> Sam Mason writes:
> > On Sun, Oct 04, 2009 at 01:44:30AM -0700, tomrevam wrote:
> >> -> Bitmap Index Scan on session_allocation_info_status_idx
> >> (cost=0.00..5.28 rows=1 width=0) (actual time=1619.652..1619.652
> >> rows=51025 loops
On Sat, Oct 03, 2009 at 10:14:53PM -0400, V S P wrote:
> Withing PG procedures at least in pgsql it is impossible to do 'money'
> calculations without a loss of precision.
The point is that on *any* computer it's impossible to perform arbitrary
calculations to infinite precision (i.e. "without a l
On Sun, 4 Oct 2009, Sam Mason wrote:
Withing PG procedures at least in pgsql it is impossible to do 'money'
calculations without a loss of precision.
The point is that on *any* computer it's impossible to perform arbitrary
calculations to infinite precision (i.e. "without a loss of precision a
I am working actually in an replication project. I need a trigger function but
when I compile this, the C compilator return the log message:
# cc -fpic -c main.c
In file included from /usr/include/postgresql/postgres.h:49,
from main.c:1:
/usr/include/postgresql/utils/elog.h:68:
On Sun, Oct 04, 2009 at 11:39:32AM -0400, Yadisnel Galvez Velazquez wrote:
>
> I am working actually in an replication project. I need a trigger
> function but when I compile this, the C compilator return the log
> message:
Please include the actual code, or at least a pointer to your source
code
I am working actually in an replication project. I need a trigger function but
when I compile this, the C compilator return the log message:
# cc -fpic -c main.c
In file included from /usr/include/postgresql/postgres.h:49,
from main.c:1:
/usr/include/postgresql/utils/elog.h:68:28
Yadisnel Galvez Velazquez wrote:
> I am working actually in an replication project. I need a trigger function
> but when I compile this, the C compilator return the log message:
>
> # cc -fpic -c main.c
You're missing some -I directives (among other things). I suggest you
compile this way:
cc
On Sun, Oct 04, 2009 at 01:07:54PM -0400, Yadisnel Galvez Velazquez wrote:
> The problem is identical if I run this example:
Please attach files instead of posting them in-line :) I've attached
your example as a file.
Please also to group-reply instead of just replying to the poster.
Cheers,
Da
The problem is identical if I run this example:
#include
#include
#include
extern Datum trigf(PG_FUNCTION_ARGS);
PG_FUNCTION_INFO_V1(trigf);
Datum
trigf(PG_FUNCTION_ARGS)
{
TriggerData *trigdata = (TriggerData *) fcinfo->context;
TupleDesc tupdesc;
HeapTuple rettuple;
cha
Hello,
I'm playing with postgres in OpenVZ. When I migrate my machine with
the database from one host to another I get following errors:
2009-10-04 20:20:43 CEST PANIC: hash table "LOCK hash" corrupted
2009-10-04 20:20:43 CEST STATEMENT: begin
2009-10-04 20:20:43 CEST @ LOG: server process (P
Gerhard Heift writes:
> I'm playing with postgres in OpenVZ. When I migrate my machine with
> the database from one host to another I get following errors:
> 2009-10-04 20:20:43 CEST PANIC: hash table "LOCK hash" corrupted
> 2009-10-04 20:20:43 CEST STATEMENT: begin
> 2009-10-04 20:20:43 CEST
On Sun, Oct 04, 2009 at 09:31:02AM -0700, Rich Shepard wrote:
> On Sun, 4 Oct 2009, Sam Mason wrote:
> >The point is that on *any* computer it's impossible to perform arbitrary
> >calculations to infinite precision (i.e. "without a loss of precision as
> >you put it).
>
> I've not followed this
On Fri, 2 Oct 2009, Greg Smith wrote:
On Fri, 2 Oct 2009, Scott Marlowe wrote:
I found that lowering checkpoint completion target was what helped.
Does that seem counter-intuitive to you?
I set it to 0.0 now.
Generally, but there are plenty of ways you can get into a state where a
short
Rich Shepard wrote:
In the early and mid-1980s we used a procedure for business
applications
involving money that worked regardless of programming language or
platform.
To each (float, real) monetary amount we added 0.005 and truncated the
result
to two digits on the right of the decimal
Sam Mason wrote:
>> > 8.4 has a generate_series(timestamp,timestamp,interval) which would seem
>> > to be a bit more flexible than you want.
>> Yes, I know :-). But as "generate_series(A, B, C)" can also
>> be written as "A + generate_series(0, (C - B) / C) * C" (or
>> something "flexible" like
In 8.4.1, trying to load a dump from 8.3.5, I get that error from this
statement:
CREATE TABLE "PatientDocument" (
)
INHERITS ("PatientRelated", "Document");
But I do not see any conflict:
# \d "PatientRelated"
Table "v2.PatientRelated"
Column | Type |
Scott Ribe writes:
> Should I really have to re-specify the default in this case???
Works for me:
regression=# create sequence s1;
CREATE SEQUENCE
regression=# create table t1 (f1 bigint default nextval('s1'::text::regclass));
CREATE TABLE
regression=# create table t2 (f1 bigint default nextval(
> Can you show an actual test case?
create sequence "DbRowIds";
create table "PatientRelated" (id int8 not null default
nextval('"DbRowIds"'));
create table "Document" (id int8 not null default nextval('"DbRowIds"'));
create table "PatientDocument" () inherits ("PatientRelated", "Document");
Rich Shepard wrote:
On Sun, 4 Oct 2009, Sam Mason wrote:
Withing PG procedures at least in pgsql it is impossible to do 'money'
calculations without a loss of precision.
The point is that on *any* computer it's impossible to perform arbitrary
calculations to infinite precision (i.e. "without
Scott Ribe writes:
>> Can you show an actual test case?
> create sequence "DbRowIds";
> create table "PatientRelated" (id int8 not null default
> nextval('"DbRowIds"'));
> create table "Document" (id int8 not null default nextval('"DbRowIds"'));
> create table "PatientDocument" () inherits ("
On Oct 4, 2009, at 7:09 PM, Guy Rouillier wrote:
There is no reason why PG could not support packed decimal.
Is that not NUMERIC?
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://w
I just did an upgrade on two of my servers (the main and the
failover). The main went OK but the postgres on the failover won't
start.
Unfortunately there is nothing anywhere telling me what the problem
is. The log file is empty, there is nothing in the /var/log/messages
or /var/log/syslog either.
I'm running our products test suite against PostgreSQL 8.4.1. The test
suite runs fine against 8.3.7.
With 8.4.1, some of our tests are failing with the exception
'attempted to lock invisible tuple'. The failures are repeatable -
they crash every time at the same point. They crash no matter if the
30 matches
Mail list logo
