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)
- Bitmap
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: scanned
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
Sam Mason s...@samason.me.uk 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)
-
tomrevam to...@fabrix.tv 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:
On Sun, Oct 04, 2009 at 11:08:01AM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk 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
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
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
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:
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:
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,
The problem is identical if I run this example:
#include postgresql/8.3/server/postgres.h
#include postgresql/8.3/server/executor/spi.h
#include postgresql/8.3/server/commands/trigger.h
extern Datum trigf(PG_FUNCTION_ARGS);
PG_FUNCTION_INFO_V1(trigf);
Datum
trigf(PG_FUNCTION_ARGS)
{
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
Gerhard Heift ml-postgresql-20081012-3...@gheift.de 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:
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 tread,
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 s...@samason.me.uk 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 |Modifiers
Scott Ribe scott_r...@killerbytes.com 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
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);
--
Scott Ribe
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 scott_r...@killerbytes.com 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 ()
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:
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
29 matches
Mail list logo
