Try to reduce confusion about what is a lock method identifier, a lock
method control structure, or a table of control structures.
. Use type LOCKMASK where an int is not a counter.
. Get rid of INVALID_TABLEID, use INVALID_LOCKMETHOD instead.
. Use INVALID_LOCKMETHOD instead of (LOCKMETHOD)
On Mon, 8 Sep 2003 00:51:45 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
This has been saved for the 7.5 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
Here is the combined patch. Prior patches in this thread are hereby
obsolete.
Servus
Manfred
diff -ruN
On Mon, 8 Sep 2003 13:02:11 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
Manfred, can I get a description for this patch? Thanks.
Try to reduce confusion about what is a lock method identifier, a lock
method control structure, or a table of control structures.
. Use type LOCKMASK where
On Sun, 07 Sep 2003 12:23:28 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Maybe so, but it would degrade the performance in the unique-index case
if we do it as the TODO is worded.
The patch would only hurt with a unique index, if there are lots of
duplicate tuples at CREATE INDEX time.
My own
On Sun, 7 Sep 2003 11:43:42 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
I assume this completes this TODO:
* Order duplicate index entries by tid for faster heap lookups
I don't think so, because the patch does nothing to keep the sort
order once the index is initially created.
On Mon, 8 Sep 2003 11:31:05 +0200, Zeugswetter Andreas SB SD
[EMAIL PROTECTED] wrote:
As Tom mentioned, we might not want to keep the tid's in order after the
index is created because he wants the most recent tid's first, so the
expired ones migrate to the end.
But on average this argument
With pg_autovacuum becoming increasingly popular it's important to
have a working stats collector. This test is able to discover the
problem that was present in 7.4 Beta 2.
Servus
Manfred
diff -ruN ../base/src/test/regress/expected/stats.out
src/test/regress/expected/stats.out
---
On Thu, 11 Sep 2003 23:17:13 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
The stats collector is on by default (of course, that doesn't apply to
make installcheck...)
By doing appropriate changes to your installation I guess you can
break almost every test ;-)
Oh I see now, nice. I
On Sun, 05 Oct 2003 19:12:50 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
it seems we have to compare the null representation string to the
pre-debackslashing input.
Here is a patch that does this and adds a few regression tests.
(This is probably fairly easy to make happen
in CVS tip, but it might
On Wed, 08 Oct 2003 11:31:30 +0200, I wrote:
There haven't been too much changes in this area between 7.3 and 7.4.
Here is the patch for 7.3.4 ...
Bruce, I noticed that the original patch submission didn't contain
anything useful as a cvs log message:
Make COPY FROM a bit more compatible with
On Wed, 8 Oct 2003 11:33:24 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
Can someone explain what was broken?
COPY FROM removed backslashes before comparing the input to the
external null representation. (It had a hard-wired special code path
that allowed \N to be recognized.) The text
On Tue, 30 Sep 2003 20:00:22 -0400, Neil Conway [EMAIL PROTECTED]
wrote:
This patch adds a new GUC var, default_use_oids
Shouldn't it be honoured by CREATE TABLE AS SELECT ... ?
This checkin might contain hints to the places that have to be
modified:
2003-01-23 tgl
*
On Mon, 01 Dec 2003 13:32:10 -0500, Tom Lane [EMAIL PROTECTED] wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
comparetup_index() compares two IndexTuples. The structure
IndexTupleData consists basically of not much more than an ItemPointer,
and the patch is not much more than adding
On Mon, 05 Apr 2004 15:37:07 -0400, Tom Lane [EMAIL PROTECTED] wrote:
I wouldn't bother with a GUC variable for the production patch.
Among other things the GUC variable will be thrown out for the final
version.
Once a block is selected for inspection, all tuples of this
block are accessed to
On Mon, 05 Apr 2004 18:30:29 -0400, Tom Lane [EMAIL PROTECTED] wrote:
noise-contributing factors.
I think it would have to be visibility-bit updates. Can you try it with
a pre-vacuumed relation, so that there is no slowdown for updates?
I'd like to avoid VACUUM to keep the dead tuples.
On Wed, 28 Apr 2004 12:02:44 -0400, Alvaro Herrera
[EMAIL PROTECTED] wrote:
In fact, I think we should mark ERROR as aborting the whole transaction
tree, and create a new level which would abort the innermost
subtransaction. We would then change whatever is appropiate to the new
elevel. Doing
Yesterday's snapshot couldn't be compiled from a separate build
directory, and after configure --without-docdir ... make install failed,
because it tried to mkdir /postgresql/html.
The enclosed patch fixes these problems, at least for me.
Servus
Manfred
diff -Ncr ../base/src/Makefile.global.in
This patch implements the new tuple sampling method as discussed on
-hackers and -performance a few weeks ago.
Large DB -hackers 2004-04-02
query slows down with more accurate stats -perform 2004-04-13
Tuple sampling -hackers 2004-04-19
Servus
Manfred
diff -rcN
On Sun, 23 May 2004 13:16:49 -0400, Tom Lane [EMAIL PROTECTED] wrote:
$ gcc --version
2.7.2.1
Man, that's ancient.
Don't say that before you have seen my bike :-)
How do you feel about upgrading?
This is on my notebook. I'm a little afraid of changing major parts of
the system. Once I
On Sun, 23 May 2004 17:32:36 -0400, Tom Lane [EMAIL PROTECTED] wrote:
I took out the TupleCount typedef and went
back to using doubles for the tuple counts; this is more consistent with
the coding style used elsewhere, and I really doubt that it's any
slower.
Performance was not the primary
Basically replaces (*a).b with a-b as it is everywhere else in
Postgres.
Servus
Manfred
diff -Ncr ../base/src/backend/storage/page/bufpage.c src/backend/storage/page/bufpage.c
*** ../base/src/backend/storage/page/bufpage.c Sat Nov 29 20:51:57 2003
--- src/backend/storage/page/bufpage.c Wed Jun
. rename variables
. cur_buffer - dst_buffer
. ToPage - dst_page
. cur_page - dst_vacpage
. move variable declarations into block where variable is used
. various Asserts instead of elog(ERROR, ...)
. extract functionality from repair_frag() into new routines
.
The comment describing cost_nonsequential_access() says that the two
functions meet in the middle. They meet at random_page_cost/2,
however, not in the middle between 1 and random_page_cost. For
random_page_cost 2 the result can be less than 1 for relpages near
effective_cache_size. I don't
On Tue, 08 Jun 2004 11:13:43 -0400, Tom Lane [EMAIL PROTECTED] wrote:
This patch seems to do considerably more violence to the equations than
is needed to cover that oversight, though. The old behavior was
intentionally nonlinear in relsize; this is not.
The comment says entirely ad-hoc and I
On Tue, 08 Jun 2004 13:13:01 -0400, Tom Lane [EMAIL PROTECTED] wrote:
Possibly the relsize axis ought to be measured on a log scale, or
something like that, but that didn't seem to work nicely when relsize
approaches zero.
In my experiments I used log(relsize) on the x axis, and I don't think
On Tue, 18 Jan 2005 16:15:57 +1100, Neil Conway [EMAIL PROTECTED]
wrote:
900 line functions are almost
universally bad
Amen. So you might be interested in reviewing
http://archives.postgresql.org/pgsql-hackers/2004-06/msg00398.php ;-)
Servus
Manfred
---(end of
26 matches
Mail list logo
