Jeff Davis wrote:
On Fri, 2008-02-01 at 15:42 +, Luke Porter wrote:
All
Is there an interest in developing bitemporal functionality in
PostgreSQL
I am very interested in this topic, and I maintain the pgsql-temporal
project at:
http://pgfoundry.org/projects/temporal/
It's missing
On Sat, Feb 02, 2008 at 09:49:05PM +0100, Florian G. Pflug wrote:
AFAICS, memory overcommit helps if a program creates 50mb of mosty
read-only data, and than forks 10 times, or if it maps a large amount of
memory but writes to that block only sparsely. Since postgres does
neither, a dedicated
Martijn van Oosterhout wrote:
On Sat, Feb 02, 2008 at 09:49:05PM +0100, Florian G. Pflug wrote:
AFAICS, memory overcommit helps if a program creates 50mb of mosty
read-only data, and than forks 10 times, or if it maps a large amount of
memory but writes to that block only sparsely. Since
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Sat, Feb 02, 2008 at 09:49:05PM +0100, Florian G. Pflug wrote:
AFAICS, memory overcommit helps if a program creates 50mb of mosty
read-only data, and than forks 10 times, or if it maps a large amount of
memory but writes to that block only
On Sat, 2008-02-02 at 17:38 -0500, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Sat, Feb 02, 2008 at 05:23:39PM -0500, Christopher Browne wrote:
I think it would be nice to be able to have more trigger hooks
relating to DDL changes, but I also think that will represent some
Martijn van Oosterhout [EMAIL PROTECTED] writes:
Now, postgres almost certainly will never change much of it so it's not
a big deal, but it could if it wanted to and that what overcommit was
designed for: banking on the fact that 99% of the time, that space
isn't written to. Overcommit is
When PostgreSQL 8.4 development opens, I would like to upgrade to Autoconf
2.61. This has been out for over a year now, and many developers will
probably find it to be available through their operating system distributor
already. If not, consider installing it sometime if you plan to modify
Oleg Bartunov wrote:
On Sat, 2 Feb 2008, Gurjeet Singh wrote:
Hi All,
I just noticed a minor bug in our search results. Searching for
is_insteadbool in 8.3 docs returns the following page:
http://www.postgresql.org/docs/8.3/static/catalog-pg-rewrite.html
is_instead is a column, and
On Sun, 2008-02-03 at 10:48 +, Heikki Linnakangas wrote:
I don't know what bitemporal is all about, but to me, the
pgsql-temporal approach is clearly the most flexible and attractive.
I think what he means by bitemporal is what CJ Date, et al., refer to
as fully temporal (as opposed to
On Sun, 3 Feb 2008, Jeff Davis wrote:
I think what he means by bitemporal is what CJ Date, et al., refer to
as fully temporal (as opposed to semi-temporal), that is, dealing with
time intervals rather than time points.
I think fully temporal is a step of complexity above how some people use
On Feb 3, 2008 7:26 PM, Omar Bettin [EMAIL PROTECTED] wrote:
Probably I am on the wrong place but for me NULL on numbers means 0 or ZERO.
I know about standards...
NULL means unknown value, ZERO is a known value
--
regards,
Jaime Casanova
Programming today is a race between software
Probably I am on the wrong place but for me NULL on numbers means 0 or ZERO.
I know about standards...
but I think that integralism is somewhat wrong.
Omar
a programmer...
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will
Hi All,
I have wanted to create a reverse key index for some time now, and it
seems that an evening of reading and half a day of efforts finally paid off.
This is just a proof of concept, and sure, the bit-reversing technique can
use a native language's power for better results.
I
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Simon Riggs wrote:
One fairly obvious difficulty is how to pass the trigger any meaningful
information about what happened (or is about to happen). In the case of
TRUNCATE, pretty much everything you need to know is implicit in the
event
Hi,
I have a doubt referring to following scenario:
create table t1 (id integer primary key,desc varchar(10));
I insert 4 values as below:
id val
---
1 one
2 two
3 three
4
[EMAIL PROTECTED] writes:
There will be one block/page/buffer allocated for table t1 and the
values are inserted to that block. When a commit is issued after
insert, the data is guranteed to be written to the datafile on the
disk. Now when the couple of updates are done from 2 sessions
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
As Tom stated it earlier, the ANALYZE slow down is far from being the
only consequence. The planner will also have more work to do and
that's the hard point IMHO.
Without studying the impacts of this change on a large set of queries
in
17 matches
Mail list logo
