...
> (1) Major version upgrade. This is a hard one, having to dump out and restore a
> database to go from 7.1 to 7.2 or 7.2 to 7.3 is really a hard sell.
Hmm, maybe it would be more acceptable if we charged $40k per license,
but refunded $40k if you *want* to dump/reload. Gets that motivation
l
I said:
> Sorry, you used up your chance at claiming that t_hoff is dispensable.
> If we apply your already-submitted patch, it isn't.
Wait, I take that back. t_hoff is important to distinguish how much
bitmap padding there is on a particular tuple --- but that's really
only interesting as long
Tom Lane wrote:
>
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Well, I guess that just saved *me* alot of work ... thanks ...
>
> Uh, not yet. Don't you still need a semaphore implementation that
> works on Windows?
>
I have a LOT of experience with Windows development. You tell me wh
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Well, I guess that just saved *me* alot of work ... thanks ...
Uh, not yet. Don't you still need a semaphore implementation that
works on Windows?
regards, tom lane
---(end of broadcast)---
I said:
> On the other hand --- if the index *is* unique, and we are checking
> equality on all columns (a fairly easily checked condition), then we
> know we should retrieve at most one visible tuple. So, without making
> any incorrect assumptions, we could terminate the indexscan after the
> fi
Well, I guess that just saved *me* alot of work ... thanks ...
On Sat, 4 May 2002, Tom Lane wrote:
> mlw <[EMAIL PROTECTED]> writes:
> > We could provide a PGSemaphore based on an APR mutex and a counter,
> > but I'm not sure of the performance impact. We may want to implement a
> > "generic" s
On Sat, 4 May 2002, mlw wrote:
> Upon doing some inspection of apache 2.x, it seems that me making a SysV
> Windows .DLL for PostgreSQL, while a cool project, would be unnecessary.
>
> The APR (Apache Portable Runtime) seems to have all the necessary support. The
> problem is that it has its own
> IMHO, the current ADD COLUMN mechanism is a hack. Besides requiring
> redundant on-disk data (t_natts), it isn't SQL compliant (because
> default values or NOT NULL can't be specified), and depends on
> a low-level kludge (that the storage system will return NULL for
> any attnums > the # of the
> (For others: apparently PG will work under BSD jails if you recompile the
> BSD kernel w/some new settings, but my ISP for this project was
> unwilling to
> do that. Search the mailing list for messages on how to do this.)
Works fine. You don't need to recompile - just use the sysctl.
Chris
Neil Conway <[EMAIL PROTECTED]> writes:
> IMHO, the current ADD COLUMN mechanism is a hack. Besides requiring
> redundant on-disk data (t_natts), it isn't SQL compliant (because
> default values or NOT NULL can't be specified), and depends on
> a low-level kludge (that the storage system will retu
> > Rather than propagating the SysV semaphore API still further, why don't
> > we kill it now? (I'm willing to keep the shmem API, however.)
>
> Would this have the benefit of allow PostgreSQL to work properly in BSD
> jails, since lack of really working SysV IPC was the problem there?
I have p
On Sunday 05 May 2002 02:46 pm, Jack Bates wrote:
> CVSROOT=:pserver:[EMAIL PROTECTED]:/projects/cvsroot
> Still no tag for 7.2.1.
> Could I (again) request that a tag be set for the current public release
> of this product?
Why? There is typically a REL tag set for the major, then a REL PATCH
On Mon, 6 May 2002 08:44:27 +0900
"Hiroshi Inoue" <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: Manfred Koizar
> >
> > If there is interest in reducing on-disk tuple header size and I have
> > not missed any strong arguments against dropping t_natts, I'll
> > investigate fur
> -Original Message-
> From: Manfred Koizar
>
> If there is interest in reducing on-disk tuple header size and I have
> not missed any strong arguments against dropping t_natts, I'll
> investigate further. Comments?
If a dbms is proper, it prepares a mechanism from the first
to handle A
Manfred Koizar <[EMAIL PROTECTED]> writes:
> Currently there's an int16 t_natts in HeapTupleHeaderData. This
> number is stored on disk for every single tuple. Assuming that the
> number of attributes is constant for all tuples of one relation we
> have a lot of redundancy here.
... but that's
"Cyril VELTER" <[EMAIL PROTECTED]> writes:
> I find the semaphore API quite clean but have some question on the
> Shared memory one. The Id's passed to PGSharedMemoryIsInUse aren't clear to
> me. How id1 and id1 are related to the port parameter of
> PGSharedMemoryCreate ?
You can define 'em
> -Original Message-
> From: Ron Snyder [mailto:[EMAIL PROTECTED]]
>
> Although I can't tell for sure, I really don't think it's the
> output of the UPDATE 0 that is causing the problem.
You may have other problems.
However you can't get expected results anyway
as long as you are using
On Sun, 5 May 2002 18:07:27 -0400, Neil Conway
<[EMAIL PROTECTED]> wrote:
>See AlterTableAddColumn() in commands/tablecmds.c
Thanks. Sounds obvious. Should have looked before asking...
This doesn't look too promising:
* Implementation restrictions: because we don't touch the table rows,
On Sun, 05 May 2002 23:48:31 +0200
"Manfred Koizar" <[EMAIL PROTECTED]> wrote:
> Two years ago there have been thoughts about ADD COLUMN and whether it
> should touch all tuples or just change the metadata. Could someone
> tell me, what eventually came out of this discussion and where I find
> th
Currently there's an int16 t_natts in HeapTupleHeaderData. This
number is stored on disk for every single tuple. Assuming that the
number of attributes is constant for all tuples of one relation we
have a lot of redundancy here.
Almost everywhere in the sources, where HeapTupleHeader->t_natts i
Tom Lane wrote:
> No. For starters, we couldn't guarantee that insertion order is the
> same as transaction commit order. Even if we did, your assumption
> that commit order is the same as visibility is too simplistic. And
> none of this works if the index isn't unique.
Ahh, I get it, (again,
Hi Tom,
I'll do the necessary change for the BeOS port. On a first look, this
will greatly simplify the semaphore layer as the new API map quite well with
the BeOS one.
I find the semaphore API quite clean but have some question on the
Shared memory one. The Id's passed to PGSharedMe
On Mon, 06 May 2002 00:50:25 +1000, the world broke into rejoicing as
Gavin Sherry <[EMAIL PROTECTED]> said:
> On Sun, 5 May 2002 [EMAIL PROTECTED] wrote:
> > On Sun, 05 May 2002 10:01:57 EDT, the world broke into rejoicing as
> > mlw <[EMAIL PROTECTED]> said:
> > > It is sunday morning and I ha
I'm using:
CVSROOT=:pserver:[EMAIL PROTECTED]:/projects/cvsroot
Still no tag for 7.2.1.
Could I (again) request that a tag be set for the current public release
of this product?
Cheers.
--
Jack Bates
Portland, OR, USA
http://www.floatingdoghead.net
Got privacy?
My PGP key: http://www.flo
I said:
> none of this works if the index isn't unique.
On the other hand --- if the index *is* unique, and we are checking
equality on all columns (a fairly easily checked condition), then we
know we should retrieve at most one visible tuple. So, without making
any incorrect assumptions, we cou
mlw <[EMAIL PROTECTED]> writes:
> I guess I don't understand. Why does it have to visit all of them?
Because it doesn't have any way to know in advance which one(s) are
visible to it.
> If ordering
> them from newest tom oldest, and then take the first transaction ID that it
> smaller then curre
Joel Burton writes:
> Feeding `pg_config --configure` into configure no longer works, as the
> output of `pg_config --configure` now includes hypens (as in
> "'--enable-cassert' '--enable-debug'"), which configure rejects.
[ apostrophes, I assume ]
Try
eval configure `pg_config --configure
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > [Index] --> [Target]->[LRU]->[1]->[2]->[3]->[MRU]
>
RE: http://archives.postgresql.org/pgsql-hackers/2002-05/msg00030.php
There are a few variations, but it seems I am making the same assumptions as
Lincln Yeoh. So, you are saying that wh
mlw <[EMAIL PROTECTED]> writes:
> [Index] --> [Target]->[LRU]->[1]->[2]->[3]->[MRU]
This diagram is entirely unrelated to reality. See, eg,
http://archives.postgresql.org/pgsql-hackers/2002-05/msg00012.php
regards, tom lane
---(end of broadcast)-
On Sun, 5 May 2002 [EMAIL PROTECTED] wrote:
> On Sun, 05 May 2002 10:01:57 EDT, the world broke into rejoicing as
> mlw <[EMAIL PROTECTED]> said:
> > It is sunday morning and I have been musing about some PostgreSQL issues. As
> > some of you are aware, my dot com, dot died, and I am working on
"Joel Burton" <[EMAIL PROTECTED]> writes:
> Would this have the benefit of allow PostgreSQL to work properly in BSD
> jails, since lack of really working SysV IPC was the problem there?
>>
>> Was the problem just with semas, or was shmem an issue too?
> Not sure -- doesn't get far enough for me
On Sun, 05 May 2002 10:01:57 EDT, the world broke into rejoicing as
mlw <[EMAIL PROTECTED]> said:
> It is sunday morning and I have been musing about some PostgreSQL issues. As
> some of you are aware, my dot com, dot died, and I am working on a business
> plan for a consulting company which, amo
It is sunday morning and I have been musing about some PostgreSQL issues. As
some of you are aware, my dot com, dot died, and I am working on a business
plan for a consulting company which, amongst other things, will feature
PostgreSQL. As I am working on the various aspects, some issue pop up abo
Hi
I found a strange error (at least at first glance I had thought it
seems so):
mail=# select * from accounts_log where login='trading';
id | login | debet | credit | when
--+-+---+---+--
6289 | trading | 117
> Help
You are welcome.
> create table some_table (
> id int UNIQUE,
> value int
> );
> INSERT INTO some_table values(1,0);
> INSERT INTO some_table values(50,0);
I would prefer :
CREATE TRABLE table_foo (
foo_oid serial,
foo_value int
);
foo_oid will become a primary key, thus it is bein
help
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 03, 2002 3:07 PM
> To: mlw
> Cc: Marc G. Fournier; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
>
>
> mlw <[EMAIL PROTECTED]> writes:
> > I am writing a Win32 DLL imp
37 matches
Mail list logo
