My build failed in interfaces/ecpg/compatlib because the Makefile
references pgtypeslib instead of compatlib. I was wondering why
nobody else got that problem. Maybe because they have an old version
of informix.c lying around in pgtypeslib? Anyway, this patch should
fix that problem.
Servus
On Tue, 01 Apr 2003 00:29:46 -0500, Tom Lane [EMAIL PROTECTED]
wrote:
Just out of curiosity --- does MSSQL treat f1 and t1.f1 as different
in the RIGHT JOIN variant case I mentioned?
MSSQL7:
SELECT t1.f1
FROM t1 {INNER | LEFT | RIGHT} JOIN t2 ON (t1.f2=t2.f2)
GROUP BY f1
all run without an
On Wed, 19 Mar 2003 11:18:38 -0500, Tom Lane [EMAIL PROTECTED]
wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
If we set XMIN/MAX_IS_COMMITTED in a tuple header, we have to replace
a sub-transaction xid in xmin or xmax respectively with the
main-transaction xid at the same time. Otherwise we'd
On Wed, 19 Mar 2003 13:00:07 -0500, Tom Lane [EMAIL PROTECTED]
wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
And if the change is lost, it can
be redone by the next backend visiting the tuple.
Not if the subtransaction log state has been removed as no longer
needed.
But this problem
Here is, what I've put together from various messages posted
November/December last year.
. Subtrans trees
. Transaction states
. Tuple visibility
. HeapTupleSatifiesUpdate
. Shortcuts
. Still missing
. Objections and suggestions
Subtrans
[forwarding to -hackers]
On Tue, 4 Nov 2003 18:28:12 -0300, Franco Bruno Borghesi
[EMAIL PROTECTED] wrote:
Below you can find a simplified example of a real case.
I don't understand why I'm getting the john record twice.
ISTM you have found a Postgres 7.3 bug.
I get one john with
PostgreSQL
On Mon, 17 Feb 2003 09:51:54 +0800, Christopher Kings-Lynne
[EMAIL PROTECTED] wrote:
Strategy three:
begin;
lock table in exclusive mode;
update row;
if (no rows affected) insert row;
commit;
Problem - Works, but this table needs high concurrency.
Chris,
distributing congestion might improve
On Fri, 14 Feb 2003 14:12:50 +0800, Christopher Kings-Lynne
[EMAIL PROTECTED] wrote:
Here's a stab at some extra conf files. Feel free to shoot them down.
No intent to shoot anything down, just random thoughts:
effective_cache_size = 2 (~ 160 MB) should be more adequate for a
256 MB machine
On Fri, 14 Feb 2003 14:24:23 +0200, Daniel Kalchev [EMAIL PROTECTED]
wrote:
The default [cache] on BSD systems is 10% of the total RAM, so on a 256MB machine
this
would be ~26MB or effective_cache_size = 32000.
I was a bit too Linux-minded, where every peace of memory not needed
for anything
On Wed, 12 Feb 2003 17:42:44 -0500, Tom Lane [EMAIL PROTECTED]
wrote:
Instead of an actively maintained freelist on disk as per Alvaro Herrera's
patch, I plan to use the FSM to remember where recyclable pages are, much
as we do for tables.
Given that we have a mostly empty metapage per index, and
On Thu, 13 Feb 2003 19:24:13 -0500, Patrick Macdonald
[EMAIL PROTECTED] wrote:
I know Oracle and DB2 have incremental backup in their arsenal (and iirc,
SQL Server has something called differential backup). Whatever the name,
it's a win at the enterprise level.
A differential backup copies only
On 17 Jan 2003 19:08:06 -0500, Greg Stark [EMAIL PROTECTED] wrote:
Would this query be efficient if there's an index on item_id, price ? That is,
would it know to do an index scan
Yes, at least to avoid the sort step.
and be able to skip to the next item_id in
the index as soon as a price was
On 17 Jan 2003 15:12:58 -0500, Greg Stark [EMAIL PROTECTED] wrote:
SELECT item.*, store.*, x.lowest_price
FROM item, store, (
SELECT item_id,
min(price) AS lowest_price,
lookup_min(price,store_id) AS lowest_price_store
FROM items_for_sale
On 14 Jan 2003 10:54:29 -0500, Robert Treat
[EMAIL PROTECTED] wrote:
Changed = the number of pages that had to be modified.
This counts only pages changed due to heap tuple header updates
(FrozenTransactionId, hint bits). It does not count page changes due
to removal of dead tuples, cf. Julian's
On Fri, 03 Jan 2003 15:37:56 -0500, Tom Lane [EMAIL PROTECTED] wrote:
The system tables are not the problem. [...]
Changes in the on-disk representation of user tables would be harder to
deal with, but they are also much rarer (AFAIR we've only done that
twice: WAL required additions to page and
On Tue, 07 Jan 2003 11:18:15 +0100, I wrote:
what I have hacked together yesterday afternoon:
[included it twice]
Sorry!
Servus
Manfred
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
On Thu, 2 Jan 2003 01:44:21 -0500, Serguei Mokhov [EMAIL PROTECTED] wrote:
Either way, something has to be donw about this...
Just another way to do it:
#if defined(HAVE_GETOPT_LONG)
#define PARMPREFIX '='
#else
#define PARMPREFIX ' '
#endif
static void
explain_option(char *shortform, char
On Sun, 29 Dec 2002 16:39:37 -0800, Kevin Brown [EMAIL PROTECTED]
wrote:
Okay. But then doesn't it make sense for FETCH to fetch the contents
of the row (and subsequent requested rows) that the cursor is
currently on *then* move, and not the other way around?
This model is extremely common
On Sun, 15 Dec 2002 23:49:57 -0300, Alvaro Herrera
[EMAIL PROTECTED] wrote:
PageGetMaxOffsetNumber (the upper bound) returns a consistent value
that's far too high (4294967291, 0xFFFB)
Alvaro, maybe this comment from bufpage.h can shed some light on it?
/*
* PageGetMaxOffsetNumber
*
[Sorry for the delay. I'm a bit busy these days.]
On Fri, 29 Nov 2002 15:57:17 -0500 (EST), Bruce Momjian
[EMAIL PROTECTED] wrote:
BTW, I think this *forces* us to replace the sub xid with the
respective main xid in a tuple header, when we set
XMIN/MAX_IS_COMMITTED. Otherwise we'd have to
On Thu, 28 Nov 2002 21:46:09 -0500, Tom Lane [EMAIL PROTECTED]
wrote:
Manfred suggested a separate log file (pg_subclog or some such) but
I really don't see any operational advantage to that. You still end up
with 4 bytes per transaction, you're just assuming that putting them
in a different file
On Thu, 28 Nov 2002 12:59:21 -0500 (EST), Bruce Momjian
[EMAIL PROTECTED] wrote:
Yes, locking is one possible solution, but no one likes that. One hack
lock idea would be to create a subtransaction-only lock, [...]
[...] without
having to touch the xids in the tuple headers.
Yes, you could do
On Fri, 29 Nov 2002 13:33:28 -0500, Tom Lane [EMAIL PROTECTED]
wrote:
Unfortunately this discussion is wrong. User-level visibility checks
will usually have to fetch the parentxid in case 01 as well, because
even if the parent is committed, it might not be visible in our
snapshot.
Or we don't
On 27 Nov 2002 11:51:13 -0500, Neil Conway [EMAIL PROTECTED] wrote:
Somewhat -- SQL2003 defines sequence generators that are pretty much
identical in functionality to PostgreSQL's sequences, although the
syntax is a bit different. I submitted a patch for 7.4 that adjusts the
CREATE SEQUENCE
On Wed, 27 Nov 2002 22:47:33 -0500 (EST), Bruce Momjian
[EMAIL PROTECTED] wrote:
The interesting issue is that if we could set the commit/abort bits all
at the same time, we could have the parent/child dependency local to the
backend --- other backends don't need to know the parent, only the
On Fri, 22 Nov 2002 00:32:46 -0500 (EST), Bruce Momjian
[EMAIL PROTECTED] wrote:
I am going to work on nested transactions for 7.4.
[...]
And finally, I must abort tuple changes made by the aborted
subtransaction. One way of doing that is to keep all relation id's
modified by the transaction,
On Wed, 13 Nov 2002 14:22:51 -0800 (PST), Stephan Szabo
[EMAIL PROTECTED] wrote:
Right now, I know that it has a hole that lets through invalid data
Stephan, your patch has been posted to -general (Subject: Re:
[GENERAL] Help..Help...). Is this version still valid?
void
Alvaro,
some time ago I started to collect ideas for btree reorganization but
never got beyond brainstorming. Maybe it helps if I add them to your
ideas ...
On Tue, 22 Oct 2002 00:12:30 -0300, Alvaro Herrera
[EMAIL PROTECTED] wrote:
I propose instead an hybrid approach: the metapage has an
On Wed, 09 Oct 2002 10:00:03 +0200, I wrote:
here is an implementation of a set of user types: char3, char4,
char10.
New version available. As I don't want to spam the list with various
versions until I get it right eventually, you can get it from
On Mon, 07 Oct 2002 15:07:29 +0530, Shridhar Daithankar
[EMAIL PROTECTED] wrote:
Only worry is database size. Postgresql is 111GB v/s 87 GB for mysql.
Shridhar,
here is an implementation of a set of user types: char3, char4,
char10. Put the attached files into a new directory contrib/fixchar,
On Wed, 09 Oct 2002 09:32:50 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Coupla quick comments on these:
My first attempt on user types; thanks for the tips.
These functions are dangerous as written, because they will crash on
null inputs. I'd suggest marking them strict in the function
On Mon, 07 Oct 2002 15:07:29 +0530, Shridhar Daithankar
[EMAIL PROTECTED] wrote:
Only worry is database size. Postgresql is 111GB v/s 87 GB for mysql. All
numbers include indexes. This is really going to be a problem when things are
deployed. Any idea how can it be taken down?
Shridhar,
if
On Mon, 07 Oct 2002 19:48:31 +0530, Shridhar Daithankar
[EMAIL PROTECTED] wrote:
I say if it's a char field, there should be no indicator of length as it's not
required. Just store those many characters straight ahead..
This is out of reach for a quick hack ...
Sure. But the server machine is
On Sat, 5 Oct 2002 00:29:03 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
OK, are we agreed to leave CURRENT_TIMESTAMP/now() alone and just add
now(string)? If no one replies, I will assume that is a yes and I
will add it to TODO.
So my view of CURRENT_TIMESTAMP not being spec compliant
On Thu, 03 Oct 2002 14:50:00 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
indexCorrelation is calculated by dividing the correlation of the
first index column by the number of index columns.
Yeah, I concluded later that that was bogus. I've been thinking of
just using the correlation of the first
On Thu, 3 Oct 2002 10:45:08 -0600 (MDT), scott.marlowe
[EMAIL PROTECTED] wrote:
effective cache size is the default (i.e. commented out)
The default is 1000, meaning ca. 8 MB, which seems to be way too low.
If your server is (almost) exclusively used by Postgres, try setting
it to represent
On Thu, 3 Oct 2002 22:21:27 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
so I propose we handle
INSTEAD rules this way: that we return the oid and tuple count of the
last INSTEAD rule query with a tag matching the main query.
Bruce, this won't work for this example
CREATE RULE
On Wed, 02 Oct 2002 18:48:49 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
I don't think it's really a good idea to expect users to pick among
multiple cost functions
The idea is that PG is shipped with a default representing the best of
our knowledge and users are not encouraged to change it. When
On Wed, 2 Oct 2002 14:07:19 -0600 (MDT), scott.marlowe
[EMAIL PROTECTED] wrote:
I'd certainly be willing to do some testing on my own data with them.
Great!
Gotta patch?
Not yet.
I've found that when the planner misses, sometimes it misses
by HUGE amounts on large tables, and I have been
On Wed, 2 Oct 2002 14:07:19 -0600 (MDT), scott.marlowe
[EMAIL PROTECTED] wrote:
I'd certainly be willing to do some testing on my own data with them.
Gotta patch?
Yes, see below. Disclaimer: Apart from make; make check this is
completely untested. Use at your own risk. Have fun!
Servus
On Thu, 03 Oct 2002 12:40:20 +0200, I wrote:
Gotta patch?
Yes, see below.
Oh, did I mention that inserting some break statements after the
switch cases helps a lot? :-(
Cavus venter non laborat libenter ...
Servus
Manfred
---(end of
On Wed, 2 Oct 2002 14:07:19 -0600 (MDT), scott.marlowe
[EMAIL PROTECTED] wrote:
I've found that when the planner misses, sometimes it misses
by HUGE amounts on large tables,
Scott,
yet another question: are multicolunm indices involved in your
estimator problems?
Servus
Manfred
On Thu, 3 Oct 2002 10:59:54 -0600 (MDT), scott.marlowe
[EMAIL PROTECTED] wrote:
are multicolunm indices involved in your estimator problems?
No. Although I use them a fair bit, none of the problems I've encountered
so far have involved them. But I'd be willing to setup some test indexes
and
On Thu, 03 Oct 2002 21:47:03 +0530, Shridhar Daithankar
[EMAIL PROTECTED] wrote:
I believe that was vacuum analyze only.
Well there is
VACUUM [tablename];
and there is
ANALYZE [tablename];
And
VACUUM ANALYZE [tablename];
is VACUUM followed by ANALYZE.
Servus
You all know this FAQ: Why does Postgres not use my index? Half of
the time this problem can easily be solved by casting a literal to the
type of the respective column; this is not my topic here.
In many other cases it turns out that the planner over-estimates the
cost of an index scan.
On Mon, 30 Sep 2002 15:29:07 -0400, Mike Mascari [EMAIL PROTECTED]
wrote:
I'm wondering how the others handle multiple
references in CURRENT_TIMESTAMP in a single stored
procedure/function invocation.
MSSQL 7 seems to evaluate CURRENT_TIMESTAMP for each statement,
Interbase 6 once per
On Sat, 28 Sep 2002 13:41:04 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
Does anyone else have a common rule that would return incorrect results
using the proposed rules?
CREATE VIEW twotables AS
SELECT ... FROM table1 INNER JOIN table2 ON ... ;
CREATE RULE
On Sun, 8 Sep 2002 19:50:21 -0300, Steve Howe [EMAIL PROTECTED]
wrote:
Proposal #1 (author: Steve Howe):
-
PQcmdStatus() == Should return the last executed command
#1a
or the same as the original command
#1b = #2
PQcmdTuples() == should
On 05 Sep 2002 20:27:23 +0500, Hannu Krosing [EMAIL PROTECTED] wrote:
Has anyone run any speed tests to see how 7.2 and 7.3 compare ?
Running a modified OSDB (CREATE TABLE ... WITHOUT OIDS) with 400 MB
data on a Pentium III 1 GHz, 382 MB RAM, 7200 rpm IBM 14 GB HD under
Linux, this is what I got
On Fri, 30 Aug 2002 11:57:17 -0700 (PDT), Laurette Cisneros
[EMAIL PROTECTED] wrote:
I was wondering if you could recomend a good source code db/indexer that
could be used to search through the postgresql code?
I use Source Navigator v5.1 http://sourceforge.net/projects/sourcenav/
Servus
Having contributed to the need for pg_dump/initdb/restore when
upgrading from 7.2 to 7.3, I plan to submit a patch which *could* make
future transitions easier.
bufpage.h:
typedef struct PageHeaderData
{
...
uint32 pd_type;/* kind and version */
...
}
#define
On Fri, 16 Aug 2002 01:05:07 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
P O S T G R E S Q L
7 . 3 O P E NI T E M S
improve macros in new tuple header code (Manfred)
ISTM there's no consensus about what improve means. I
On Fri, 16 Aug 2002 12:25:37 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
Manfred Koizar wrote:
This is the main point of disagreement: Tom Lane wants lighter
macros, I want heavier macros. Which direction shall we go?
Could you or Tom explain that in a way that others could
Hackers,
if the weather stays fine, I'll be offline for up to two weeks. Hope
there are no show stoppers in my recent heap tuple header changes. If
problems arise, report them here; I'll address them when I'm back.
Servus
Manfred
---(end of
On Thu, 18 Jul 2002 23:05:05 +0900 (JST), Tatsuo Ishii
[EMAIL PROTECTED] wrote:
TRAP: Failed Assertion(!(!((tp.t_data)-t_infomask (0x4000 |
0x8000))):, File: heapam.c, Line: 1315)
Tatsuo, this is unrelated to *your* work. It is a bug introduced with
my heap tuple header changes. Tom Lane has
On Tue, 16 Jul 2002 12:23:01 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
I've been thinking that it's really not a good idea to make the OID
field optional without any indication in the tuple header whether it
is present. In particular, this will make life difficult for tools
like pg_filedump that
On Mon, 15 Jul 2002 16:46:44 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
regression=# update foo set f1 = 'qq';
server closed the connection unexpectedly
Same with DELETE FROM foo;
I am not sure if this is a bug introduced by the patch, or if it's
exposed a previously lurking bug.
I suspect the
The estimator only uses effective_cache_size, it never looks at
NBuffers. So shouldn't we add
if (effective_cache_size NBuffers)
{
elog(NOTICE, adjusting effective_cache_size to %d,
NBuffers);
effective_cache_size =
Fix typo in xl_heaptid comment
Servus
Manfred
--- ../base/src/include/access/htup.h 2002-07-04 18:05:04.0 +0200
+++ src/include/access/htup.h 2002-07-05 16:52:44.0 +0200
@@ -268,15 +268,15 @@
/*
* When we insert 1st item on new page in INSERT/UPDATE
* we can (and we
As the upcoming release is breaking compatibility anyway: what do you
think about placing a magic number and some format version info into
the page header?
One 32-bit-number per page should be enough to encode page type and
version. We have just to decide, how we want it:
a) combine page type
On Tue, 2 Jul 2002 02:16:29 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
I committed the version with no #ifdef's. If we need them, we can add
them later, but it is likely we will never need them.
My point was, if there is a need to fallback to v7.2 format, it can be
done by changing a
We have been discussing heap tuple header changes for a while now.
Here is my proposal for omitting the oid, when it is not needed:
First let's eliminate t_oid from HeapTupleHeaderData.
Then add the oid to the end of the structure, if and only if it is
needed. The tricky part here is that
On Mon, 01 Jul 2002 12:40:35 +0200, I wrote:
Bytes saved on architectures with 4/8 byte alignment:
hoffbytes
natts bitmaplen hoff72 oidoff woosaved
0 28/32 2424/244/8
1-81 28/32 2424/244/8
9-40
On Mon, 10 Jun 2002 09:56:27 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Does anyone know whether other systems that support the UPDATE extension
for multiple tables also support a DELETE extension for multiple tables?
If so, what's their syntax?
MSSQL seems to guess what the user wants. All the
On Fri, 7 Jun 2002 02:01:40 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
I think it is inevitable that there be enough binary file changes the
pg_upgrade will not work for 7.3 --- it just seems it is only a matter
of time.
As far as it concerns changes proposed by me, I'll (try to)
On Mon, 27 May 2002 13:48:43 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
On leaf pages order index tuples by heap item pointer, if otherwise
equal. [blah, blah, ...]
Doesn't help, I fear. Finding your place again is only one part
of the problem
On Sat, 25 May 2002 14:21:52 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
I'm somewhat concerned that the more stringent locking will slow down
VACUUM a good deal when there's lots of concurrent activity, but I don't
see another answer. Ideas anyone?
Ideas? Always! :-) Don't know if this one is
On Thu, 23 May 2002 18:36:17 +0100 (WEST), NunoACHenriques
[EMAIL PROTECTED] wrote:
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
On Tue, 21 May 2002 12:48:39 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
4. How exactly should a killed index tuple be marked on-disk? While there
is one free bit available in IndexTupleData.t_info, I would prefer to use
that bit to expand the index tuple size field to 14 bits instead of 13.
(This
On Thu, 02 May 2002 21:10:40 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
Is saving 4 bytes per tuple a darn good reason?
[...] Now if
we could get rid of 8 bytes in the header, I'd get excited ;-)
Tom,
what about WITHOUT OIDS? I know dropping the OID
On Tue, 21 May 2002 09:57:32 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
what about WITHOUT OIDS? I know dropping the OID from some tables and
keeping it for others is not trivial, because t_oid is the _first_
field of HeapTupleHeaderData. I'm vaguely
On Tue, 21 May 2002 11:10:04 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Odd. I wonder whether you are looking at an unintended behavior of the
free space map's thresholding mechanism. The toast table will generally
have large tuples of consistent size (about 2K each).
So we have 4 tuples per
On Tue, 21 May 2002 11:53:04 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
The system tables that have OIDs will certainly continue to have OIDs.
That's clear. I should have written: ... rip out oids from tuple
headers of system tables.
Ugh. While certainly we should have been using accessor
macros
On Fri, 10 May 2002 10:51:05 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Thoughts, different proposals, alternative ways of breaking down
the problem?
Well, you asked for it, so here is my wishlist :-)
From a user POV I expect a command to return the number of rows it
has processed successfully.
On Fri, 17 May 2002 09:57:39 -0400, Joel Burton
[EMAIL PROTECTED] wrote:
-Original Message-
From: Peter Eisentraut [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 17, 2002 9:37 AM
To: Joel Burton
Cc: PostgreSQL Development
Subject: RE: [HACKERS] Updated CREATE FUNCTION syntax
I think
been use or draw from the pool of.
Should have listened better to my English teacher :-)
On Sat, 11 May 2002 11:51:37 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
TransactionId GetParentXact(TransactionId xnum) uses pg_subtrans to
find the parent transaction
Hi,
if it is acceptable for subtransactions to use up transaction numbers,
then here is a half baked RFC for a possible implementation.
If not, forget the rest of this message.
The proposed implementation works much like the current transaction
handling. It needs an additional system table
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
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,
Tom Lane wrote in another tread:
PS: I did like your point about BITMAPLEN; I think that might be
a free savings. I was waiting for you to bring it up on hackers
before commenting though...
So here we go...
Hi,
in htup.h MinHeapTupleBitmapSize is defined to be 32, i.e. the bitmap
uses at
On Thu, 02 May 2002 21:10:40 -0400, Tom Lane wrote:
Hmm ... that might work. Actually, we are trying to stuff *five*
numbers into these fields: xmin, xmax, cmin, cmax, and a VACUUM FULL
transaction id (let's call it xvac just to have a name). The code
currently assumes that cmin is not
Hi,
having been chased away from pgsql-novice by Rasmus Mohr, I come here
to try my luck :-) I'm still new to this; so please be patient, if I
ask silly questions.
There has been a discussion recently about saving some bytes per tuple
header. Well, I have the suspicion, we can eliminate 4
Tom,
thanks for answering.
On Thu, 02 May 2002 17:16:38 -0400, you wrote:
The hole in this logic is that there can be multiple active scans with
different values of CurrentCommandId (eg, within a function
CurrentCommandId may be different than it is outside). If you overwrite
cmin with cmax
101 - 183 of 183 matches
Mail list logo
