I am not sure if this could apply to your case, but maybe - unless you have
done it before -
you could look at windowing functions
Ciao Gabriele,
the problem is that the only thing the N queries have in
common is the base table; everything else is different,
because the different group
Hi,
the doc pages are somehow cryptic regarding FILLFACTOR.
(well, at least they're cryptic to me, since I don't know a lot
of btree stuff...)
I have an index on a timestamp value that is inserted, for 90%
of the inserts, in increasing order. No updates, no deletes on the
table (appends only).
On Tue, 2011-05-03 at 01:14 -0400, Tom Lane wrote:
Craig Ringer cr...@postnewspapers.com.au writes:
This message is very weird: could not read from file pg_clog/02CD at
offset 73728: Success.
Probably indicates an attempted read from beyond EOF. The main
relation-access code paths have
Hi,
I've defined a small trigger to increment a field each time the row is updated:
CREATE TRIGGER inc_trigger BEFORE UPDATE ON Table FOR EACH ROW EXECUTE
PROCEDURE inc_function();
Works quite well, however the trigger is also fired if the table
itself is modified.
When deleting or inserting
Clemens Eisserer linuxhi...@gmail.com writes:
I've defined a small trigger to increment a field each time the row is
updated:
CREATE TRIGGER inc_trigger BEFORE UPDATE ON Table FOR EACH ROW EXECUTE
PROCEDURE inc_function();
Works quite well, however the trigger is also fired if the table
Either I am exceptionally confused, or the documentation in 8.5.3 appears to be
wrong. Could someone clarify what I'm missing?
The documentation states: In short, this is the difference between
abbreviations and full names: abbreviations always represent a fixed offset
from UTC, whereas most
On Sunday, May 08, 2011 10:23:44 am Christophe Pettus wrote:
Either I am exceptionally confused, or the documentation in 8.5.3 appears
to be wrong. Could someone clarify what I'm missing?
The documentation states: In short, this is the difference between
abbreviations and full names:
On May 8, 2011, at 11:40 AM, Adrian Klaver wrote:
No, PST has an offset of -8.
Head desk. Thank you.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I only see perl-DBD-Pg 1.49 in the RHEL repos, and I don't see
perl-ExtUtils-MakeMaker in there at all (or in EPEL or in RpmForge).
For the record, only DBD::Pg is really necessary - everything will
still work fine with an older verison of
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
course, but it is trigger based. One notable difference between
Bucardo and Slony is that whereas Slony's triggers store the entire
row data in a separate log table when something changes, Bucardo
stores only the primary key.
That's
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Yeah. One nasty property that async multi master solutions share is
that they change the definition of what 'COMMIT' means -- the database
can't guarantee the transaction is valid because not all the
supporting facts are necessarily known.
Yeah. One nasty property that async multi master solutions share is
that they change the definition of what 'COMMIT' means -- the database
can't guarantee the transaction is valid because not all the
supporting facts are necessarily known. Even after libpq gives you
the green light that
12 matches
Mail list logo
