). Is this a problem do you think?
Cheers
Mark
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
recursion. :-)
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
On Fri, May 2, 2008 at 12:04 AM, Joshua D. Drake [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Mark Wong [EMAIL PROTECTED] writes:
I saw a that a patch was committed that exposed a configure switch for
BLCKSZ. I was hoping that I could do that same for XLOG_BLCKSZ.
Well, we
On Fri, May 2, 2008 at 8:50 AM, Tom Lane [EMAIL PROTECTED] wrote:
Mark Wong [EMAIL PROTECTED] writes:
As someone who has tested varying both those parameters it feels
awkward to have a configure option for one and not the other, or vice
versa. I have slightly stronger feelings
On Fri, May 2, 2008 at 9:16 AM, Tom Lane [EMAIL PROTECTED] wrote:
Mark Wong [EMAIL PROTECTED] writes:
I still believe it makes sense to have them separated. I did have
some data, which has since been destroyed, that suggested there were
some system characterization differences for OLTP
Hi all,
I saw a that a patch was committed that exposed a configure switch for
BLCKSZ. I was hoping that I could do that same for XLOG_BLCKSZ. I
think I got the configure.in, sgml, pg_config_manual.h, and
pg_config.h.in changes correct.
Regards,
Mark
Index: configure
.
Anyway, I hope I'm not way off but I'm sure someone will correct me. :)
Regards,
Mark
pgsql-log-fadvise.patch
Description: Binary data
---(end of broadcast)---
TIP 6: explain analyze is your friend
against HEAD, passes regression tests.
Cheers
Mark
Index: src/backend/commands/tablespace.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/tablespace.c,v
retrieving revision 1.51
diff -c -r1.51 tablespace.c
*** src/backend
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
I thought it made sense for CREATE TABLESPACE to attempt to create the
top level location directory -
I thought we had deliberately made it not do that. Auto-recreate during
replay sounds even worse. The problem
- So I've
submitted it as a discussion aid, rather than 'the way of fixing
this'... since I'm hoping there is a better way :-)
regards
Mark
Index: src/backend/catalog/namespace.c
===
RCS file: /projects/cvsroot/pgsql/src/backend
Alvaro Herrera wrote:
David Fetter wrote:
On Mon, May 14, 2007 at 03:31:40PM +1200, Mark Kirkwood wrote:
David Fetter wrote:
cvs diff works just great until you want to add or remove a file
without write permissions to the CVS repository, i.e. when you've
checked out as anonymous.
I usually
pgsql.orig pgsql
gives a complete patch including added/deleted files. It is a bit
primitive, but is pretty easy to do!
Cheers
Mark
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Mark Kirkwood wrote:
I have applied this to todays HEAD performed some quick tests - looks
good! I have to re-create a TPC-H dataset to test one of the previous
bugs, so I'll probably look at that tomorrow or so.
The TPC-H query query that previously produced a SIGSEGV now runs
like better the way to go (as far as I
understand the issues...). How much work is remaining on this? - not
sure that I'll have time to look at it either ... but may as well know
the size to the job :-) !
Cheers
Mark
---(end of broadcast)---
TIP
400MB 64 82 s 148 MB/s
400MB 128 93 s 128 MB/s
Certainly seems to have the desired effect!
Cheers
Mark
[1] I'm not seeing 166 MB/s like previous 8.2.3 data, however 8.3 PGDATA
is located further toward the end of the disk array - which
. Resetting the HOT-updated
status of the root tuple helps to mark the index entry LP_DELETE
once the entire HOT-update chain is dead.
...
For some reason this paragraph raised a query in my mind. Will we
be able to toggle this new hot update code at configure time, so
that we can measure what sort
for me and I don't have any objection to plperl from a security standpoint, etc.
mark
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
) and saw that back *then* 'newavg'
and 'avg' were defined using the same functions...so I think making the
change as indicated is ok.
I've attached a new patch with this change.
Cheers
Mark
diff -Nacr pgsql.orig/src/backend/utils/adt/numeric.c pgsql/src/backend/utils/adt/numeric.c
*** pgsql.orig
or GPROF_PROFILE?).
Cheers
Mark
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
.
Right - but LINUX_PROFILE was added to correct Linux specific oddities
with the time counter accumulation, whereas your patch is not Linux
specific at all. So I think a more representative symbol is required.
Cheers
Mark
---(end of broadcast)---
TIP
Mark Kirkwood wrote:
[EMAIL PROTECTED] wrote:
The name for the define variable could perhaps be better - feels
silly adding -DLINUX_PROFILE on Freebsd! (maybe just PROFILE or
GPROF_PROFILE?).
That wasn't my choice, there is other code elsewhere that depends on
that symbol, I just added
:
Note that PostgreSQL builds natively with Visual C++. You must
*therefore* ...
Cheers
Mark
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Neil Conway wrote:
On Fri, 2006-11-24 at 11:08 +1300, Mark Kirkwood wrote:
- Modifies do_numeric_accum to have an extra bool parameter and does not
calc sumX2 when it is false.
I think it would be clearer to reorganize this function slightly, and
have only a single branch on useSumX2
(1 row)
Time: 35196.028 ms
avg=# \q
regards
Mark
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls s/call s/call name
14.42 2.16 2.16 12977 0.00 0.00 AllocSetAlloc
Luke Lonergan wrote:
So, if I understand this correctly, we're calling Alloc and ContextAlloc 10
times for every row being summed?
There are approx 10M rows and the profile snippet below shows 100M calls to
each of those.
Unless I've accidentally run gprof on the profile output for a 100M
Mark Kirkwood wrote:
Luke Lonergan wrote:
So, if I understand this correctly, we're calling Alloc and
ContextAlloc 10
times for every row being summed?
There are approx 10M rows and the profile snippet below shows 100M
calls to
each of those.
Unless I've accidentally run gprof
displays all attributes bar the id as NULL). Comments?
Cheers
Mark
Index: contrib/pg_buffercache/pg_buffercache_pages.c
===
RCS file: /projects/cvsroot/pgsql/contrib/pg_buffercache/pg_buffercache_pages.c,v
retrieving revision 1.10
diff -c
,
Mark.
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
ends.
TIA,
Mark.
Index: src/backend/parser/analyze.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/parser/analyze.c,v
retrieving revision 1.351
diff -c -r1.351 analyze.c
*** src/backend/parser/analyze.c 18 Sep 2006 16:04:04 -
doesn't seem sensible. I'll have to read over the
versions again...
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder
be responsible for
outputting unique uuid values for the system. Who does this? Probably
nobody. I'm tempted to implement it, though, for my uses. :-)
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED
access to a UUID generation library. I don't
care for that convenience.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder
is possible. This is not easy
to do using a few lines of C code. I'd rather have a UUID type in core
with no generation routine, than no UUID type in core because the code
is too complicated to maintain, or not portable enough.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL
Here's an updated patch with help from Simon. Once I get a test system
going again in the lab I'll start posting some data. I'm planning a
combination of block sizes (BLCKSZ and XLOG_BLCKSZ) and number of WAL
buffers.
Thanks,
MarkIndex: src/backend/access/transam/xlog.c
On Wed, 22 Mar 2006 14:19:48 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Mark Wong [EMAIL PROTECTED] writes:
I proposed to explore splitting BLCKSZ into separate values for logging
and data to see if there might be anything to gain:
http://archives.postgresql.org/pgsql-hackers/2006-03
Mark Kirkwood wrote:
Tom Lane wrote:
I do notice a rather serious shortcoming of pg_freespacemap in its
current incarnation, which is that it *only* shows you the per-page free
space data, and not any of the information that would let you determine
what the FSM is doing to filter the raw data
).
Cheers
Mark
Index: pg_buffercache.sql.in
===
RCS file: /projects/cvsroot/pgsql/contrib/pg_buffercache/pg_buffercache.sql.in,v
retrieving revision 1.3
diff -c -r1.3 pg_buffercache.sql.in
*** pg_buffercache.sql.in 27 Feb 2006
thought so - unless there are not enough pages left in the
FSM...
pg_freespacemap is reporting on what gets into the FSM - so provided I
haven't put a bug in there somewhere (!) - we need to look at how VACUUM
reports free space to the FSM
cheers
Mark
---(end
wonder about 2 views, but was unsure if the per-relation
stuff was interesting. Given that it looks like it is interesting, I'll
see about getting a second view going.
Cheers
Mark
---(end of broadcast)---
TIP 1: if posting/reading through Usenet
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
Good points! I had not noticed this test case. Probably NULL is better
Would setting it to 'BLCKSZ - (fixed index header stuff)' be better,
No, I don't think so, because that will just make it harder to recognize
what's what
changes that have occurred.
I would include new tests in the patch but do not know on which reference
machine/platform the patches are supposed to be generated.
mark
Index: src/backend/utils/adt/timestamp.c
===
RCS file: /projects
Mark Dilger wrote:
Mark Dilger wrote:
Tom Lane wrote:
Milen A. Radev [EMAIL PROTECTED] writes:
Milorad Poluga напи�а:
SELECT '10 years 1 mons 1 days'::interval - '9 years 10 mons 15
days'::interval
?column?--- 3 mons -14 days
Why not '2 mons 16 days
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
Tom Lane wrote:
Sounds like a recipe for ensuring it never will be tested. What's
needed here is some actual tests, not preparation...
Does the OP have a test scenario that those of us with appropriate OS's
could try? Come to think
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Yes, your vote counts very much. What if I apply the patch, but mark
the posix_advise() call in a NOT_USED macro block, so it will be ready
for people to test, but will not be used until we are sure.
Sounds like a recipe
I have a fairly simple extension I want to add to contrib. It is an XML
parser that is designed to work with a specific dialect.
I have a PHP extension called xmldbx, it allows the PHP system to
serialize its web session data to an XML stream. (or just serialize
variables) PHP's normal serializer
Jim C. Nasby wrote:
On Sun, Jan 08, 2006 at 04:13:01PM +1300, Mark Kirkwood wrote:
After re-examining the original code, it looks like it was not actually
vulnerable to a race condition! (it does the UPDATE, then if not found
will do an INSERT, and handle unique violation with a repeat
Mark Kirkwood wrote:
Jim C. Nasby wrote:
On Sun, Jan 08, 2006 at 04:13:01PM +1300, Mark Kirkwood wrote:
What happens if someone deletes the row between the failed insert and
the second update? :)
In this example the rows in the summary table never get deleted by
DELETE operations
Mark Kirkwood wrote:
Jim C. Nasby wrote:
On Fri, Jan 06, 2006 at 02:00:34PM +1300, Mark Kirkwood wrote:
However, I think the actual change is not quite right - after running
DOH! It would be good if doc/src had a better mechanism for handling
code; one that would allow for writing
Jim C. Nasby wrote:
On Fri, Jan 06, 2006 at 02:00:34PM +1300, Mark Kirkwood wrote:
However, I think the actual change is not quite right - after running
DOH! It would be good if doc/src had a better mechanism for handling
code; one that would allow for writing the code natively (so you
Mark Kirkwood wrote:
Bruce Momjian wrote:
Mark Kirkwood wrote:
Simon Riggs wrote:
I like this, but not because I want to read it myself, but because I
want to make autovacuum responsible for re-allocating free space
when it
runs out. This way we can have an autoFSM feature in 8.2
direction this thread has taken - but does anybody want to
comment/review the patch itself :-) ?
Cheers
Mark
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL
to the FSM pointer itself is required, I added a
function in freespace.c to return this, rather than making it globally
visible, again if the latter is a better approach, it is easily changed.
cheers
Mark
P.s : Currently don't have access to a windows box, so had to just 'take
a stab' at what
Jim C. Nasby wrote:
Shouldn't the DDL in pg_freespacemap.sql.in be wrapped in a transaction?
Specifically I'm considering the case of the script stopping before the
REVOKEs.
That's nice, (probably should have done it in pg_buffercache )!
---(end of
Christopher Kings-Lynne wrote:
Want to host it on pgfoundry until 8.2 is released?
Absolutely - I'll let it run the gauntlet of freedback to fix the silly
mistakes I put in :-), then do patches for 8.1 and 8.0 (maybe 7.4 and
7.3 as well - if it rains a lot).
cheers
Mark
98 regression tests pass, plus it seems to
work ok :-)
test=# select ctid, id from foo where ctid != '(0,1)';
ctid | id
---+
(0,2) | 2
(0,3) | 3
(2 rows)
regards
Mark
Index: src/include/catalog/pg_proc.h
===
RCS file
Neil Conway wrote:
You also probably want to add the declaration for tidne() to
include/utils/builtins.h
Doh! - Indeed, I obviously missed a few extra compile warnings!
Revised patch attached.
Index: src/backend/utils/adt/tid.c
On Fri, 12 Aug 2005 17:49:41 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
On Fri, Aug 12, 2005 at 10:49:43AM -0700, Mark Wong wrote:
I thought I'd run a couple of tests to see if it would be helpful
against CVS from Aug 3, 2005.
Here's a run with autovacuum turned off:
http
On Fri, 12 Aug 2005 18:42:09 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
On Fri, Aug 12, 2005 at 03:16:04PM -0700, Mark Wong wrote:
On Fri, 12 Aug 2005 17:49:41 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Notice how the subindexes are wrong ... I think it should be 1:3
Mark Kirkwood wrote:
Looks to me like -O2 makes the difference very small (on this
platform/gcc combo) - is 5/169 worth doing?
Ahem - misunderstood your comment here, sorry.
Qingqing Zhou wrote:
compiled with gcc testbuf.c. I tried -O2 actually, and it turns out
that
the timing
decrease in using open_sync. Just to double check, am
I correct in understanding only open_sync uses O_DIRECT?
fdatasync
http://www.testing.osdl.org/projects/dbt2dev/results/dev4-015/38/
5462 notpm
open_sync
http://www.testing.osdl.org/projects/dbt2dev/results/dev4-015/40/
4860 notpm
Mark
Here are comments that Daniel McNeil made earlier, which I've neglected
to forward earlier. I've cc'ed him and Mark Havercamp, which some of
you got to meet the other day.
Mark
-
With O_DIRECT on Linux, when the write() returns the i/o has been
transferred to the disk.
Normally, this i
itanium2 via 6 compaq smartarray pci-x controllers.
Let me know if you have any questions.
Mark
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do
,CSV and BINARY are all parsed in CopyFrom(), like in the original file.
Hi Alon,
I'm curious, what kind of system are you testing this on? I'm trying to
load 100GB of data in our dbt3 workload on a 4-way itanium2. I'm
interested in the results you would expect.
Mark
600037902 lineitem.tbl
25 nation.tbl
15000 orders.tbl
2000 part.tbl
8000 partsupp.tbl
5 region.tbl
100 supplier.tbl
Thanks,
Mark
On Tue, 19 Jul 2005 14:05:56 -0700
Alon Goldshuv [EMAIL PROTECTED] wrote:
Hi Mark,
I improved the data *parsing
Whoopsies, yeah good point about the PRIMARY KEY. I'll fix that.
Mark
On Tue, 19 Jul 2005 18:17:52 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:
Mark,
You should definitely not be doing this sort of thing, I believe:
CREATE TABLE orders (
o_orderkey INTEGER,
o_custkey
be other instances in
-contrib, etc.
Hope this helps and that I'm not redundant with your other fans.
Regards,
Mark
userlib_link.patch
Description: Binary data
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http
, there's some good chance that the binary RPMs on the
postgresql.org FTP site have the same flaw that I encountered as
described below.
Regards,
Mark
On Wed, 6 Jul 2005 09:08:50 -0700
Mark Deric [EMAIL PROTECTED] wrote:
I built the v8.0.3 product from postgresql-8.0.3-1PGDG.src.rpm on
RedHat9
more friendly to use!
Best wishes
Mark
Index: src/backend/utils/adt/varlena.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/varlena.c,v
retrieving revision 1.125
diff -c -r1.125 varlena.c
*** src/backend/utils/adt
Alvaro Herrera wrote:
On Thu, Jul 07, 2005 at 03:01:46PM +1200, Mark Kirkwood wrote:
Neil Conway wrote:
elog(ERROR) is usually used for can't happen errors.
I have attached a little change to varlena.c that uses it. I left the
ereport as it was, but am not fussed about it either way
Neil Conway wrote:
Mark Kirkwood wrote:
I didn't performance test it, but the idea of hammering the catalogs for
each value to be processed seemed a bad thing.
Well, the syscache already sits in front of the catalogs themselves. I'd
be curious to see what the performance difference
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Thu, Jul 07, 2005 at 03:01:46PM +1200, Mark Kirkwood wrote:
I have attached a little change to varlena.c that uses it. I left the
ereport as it was, but am not fussed about it either way.
I am, because it gives useless messages
of elog.
5 Quiet compiler warning in pg_datum_length.
Best wishes
Mark
Mark Kirkwood wrote:
The next iteration -
Hopefully I have got the idea basically right.
I wonder if I have done the am I a varlena the long way.., pls advise
if so!
diff -Nacr ./doc/src/sgml/func.sgml.orig ./doc/src/sgml
The next iteration -
Hopefully I have got the idea basically right.
I wonder if I have done the am I a varlena the long way.., pls advise
if so!
Cheers
Mark
Tom Lane wrote:
My recollection of that discussion is that we just wanted something
that would return the actual VARSIZE
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
I thought I would have a look at:
(Datatypes) Add function to return compressed length of TOAST data values.
My recollection of that discussion is that we just wanted something
that would return the actual VARSIZE() of the datum
and
then updating the column to be itself will fool it).
5) Any multi-byte locale considerations?
regards
Mark
diff -Nacr src/include/catalog/pg_proc.h.orig src/include/catalog/pg_proc.h
*** src/include/catalog/pg_proc.h.orig Fri Jun 17 15:30:17 2005
--- src/include/catalog/pg_proc.h
Mark Kirkwood wrote:
Mark Kirkwood wrote:
I couldn't use int4 as the underlying datatype is unsigned int (not
available as exposed Pg type). However, using int8 sounds promising
(is int8 larger than unsigned int on 64-bit platforms?).
Blocknumber is defined as uint32 in block.h - so
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
This patch changes the use of numeric to int8 to represent the
relblocknumber column.
Applied, thanks.
This reminds me:
I did some patches for 7.4 and 8.0 a while ago (attached) - while I do
not expect these to be applied (unless
Neil Conway wrote:
On Tue, 2005-05-31 at 13:07 +1200, Mark Kirkwood wrote:
I did some patches for 7.4 and 8.0 a while ago (attached) - while I do
not expect these to be applied
Right, I don't see a need to backport this.
is there somewhere for things like this to go?
Pg Foundry
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
The handling of nulls is a little unexpected (still todo?) :
Yeah, that was broken in the first draft :-( ... I think it's OK in
the committed version though.
(post cvs update) yeah - looks good!
regards
Mark
---(end
enable_indexscan=0;
SET
regression=# select max(unique1) from tenk2;
max
--
(1 row)
cheers
Mark
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Neil Conway wrote:
Mark Kirkwood wrote:
Great that it fixes it... however, I had submitted a tidier patch that
puts the macro in the header
How is this tidier?
err... puts the macro in the header
(I don't see a reason for pg_buffercache_pages.h at all, actually.)
(chuckles) - well, that puts
about *not* having one to be honest. So, anyway - instead of
inviting Neil to spend valuable time eliminating it, I should do it
myself...
So, please ignore my previous patch to the header file, and consider
this one - which eliminates it completely.
best wishes
Mark
diff -Nacr
the
first one, oops - sorry Andrew). I have tested it on win32 native.
Do you want to back out the first one and use this instead?
regards
Mark
*** pg_buffercache_pages.h.orig Thu Mar 17 10:12:20 2005
--- pg_buffercache_pages.h Thu Mar 17 13:44:45 2005
***
*** 15,18
--- 15,24
,
XLOG_SEG_SIZE=256MB, checkpoint_segment=4
Hi Itagaki,
In light of this thread, have you compared the performance on
Linux-2.4?
Direct io on block device has performance regression on 2.6.x kernel
http://www.ussg.iu.edu/hypermail/linux/kernel/0503.1/0328.html
Mark
---(end
the issue.
One question, should I be using defined(__MINGW32__) as opposed to
defined(WIN32)? I figured I didn't as in this case it is not necessary
to distinguish between native and cygwin.
regards
Mark
*** pg_buffercache_pages.h.orig Thu Mar 17 10:12:20 2005
--- pg_buffercache_pages.h Thu Mar
A couple of minor amendments here:
- remove link to libpq (from cut+past of dblnk's Makefile)
- add comment for pg_buffercache module in contrib/README
- change my listed email to this one (I have resigned)
regards
Mark
diff -Nacr pgsql.orig/contrib/Makefile pgsql/contrib/Makefile
' and 'pg_stats', i.e. exposing some
internals in a convenient queryable manner (useful for problem solving).
On the security front, I should have added a 'REVOKE ALL ...FROM PUBLIC'
on the view to at least control access (fortunately easy to add).
cheers
Mark
---(end of broadcast
Neil Conway wrote:
Mark Kirkwood wrote:
+ TupleDescInitEntry(tupledesc, (AttrNumber) 5, relblockbumber,
+ NUMERICOID, -1, 0);
I think this should be an int4, not numeric.
I was looking for an UINT4OID :-), but numeric seemed the best
compromise (safer
if amendments are required!
Barring a huge groundswell of support for it in core :-) I will resubmit
a patch for it as a contrib module.
cheers
Mark
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe
Mark Kirkwood wrote:
Tom Lane wrote:
One reason for making it contrib is that I don't think you've got it
entirely right yet, and there will be several iterations before it
settles down. In a contrib module that is no problem, in core it's a
forced initdb each time.
Yeah - certainly less
renaming of the backend
functions happened too. Finally, since I was saving blocknum, it went
into the view as well.
Hopefully I am dealing with invalid buffer tags sensibly now. The
per-buffer spin lock is still being held - altho it is obviously trivial
to remove if not actually required.
regards
Mark
the BM_TAG_VALID or
BM_VALID flag bits (I am only checking if tag.blockNum equals
InvalidBlockNumber). My initial thought is to handle !BM_TAG_VALID or
!BM_VALID similarly to InvalidBlockNumber i.e all non buf_id fields set
to NULL.
Mark
---(end of broadcast
cleaner, so any suggestions welcome.
regards
Mark
diff -Naur pgsql.orig/src/backend/catalog/system_views.sql
pgsql/src/backend/catalog/system_views.sql
--- pgsql.orig/src/backend/catalog/system_views.sql Fri Mar 4 14:23:09 2005
+++ pgsql/src/backend/catalog/system_views.sql Fri Mar 4 14:21
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
I am using anoncvs from yesterday, so if Tom's new scheme is
*very* new I may be missing it.
It's not committed yet ;-)
Yep - that's pretty new, apologies for slow grey matter... I have been
following the discussion about the new buffer
yesterday, so if Tom's new scheme is
*very* new I may be missing it.
Thanks
Mark
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
% increase in throughput for my test. Not to shabby. ;)
Mark
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On Wed, Mar 02, 2005 at 08:48:35PM -0500, Tom Lane wrote:
Mark Wong [EMAIL PROTECTED] writes:
CVS from 20050301 [ plus clock-sweep buffer manager ] :
http://www.osdl.org/projects/dbt2dev/results/dev4-010/314/
throughput 5483.01
I only ran this for 30 minutes, as opposed to 60
!).
If it seems like a worthwhile addition I will amend the regression
expected and resubmit.
Any comments?
Mark
diff -Naur pgsql.orig/src/backend/catalog/system_views.sql
pgsql/src/backend/catalog/system_views.sql
--- pgsql.orig/src/backend/catalog/system_views.sql Thu Mar 3 11:29:55 2005
+++ pgsql
/projects/dbt2dev/results/dev4-010/312/
Throughput: 3489.69
You can verify that the wall_sync_method is set to open_direct under
the database parameters link, but I'm wondering if I missed
something. It looks a little odd the the performance dropped.
Mark
---(end
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: 17 February 2005 15:46
To: Mark Cave-Ayland
Cc: pgsql-patches@postgresql.org
Subject: Re: [PATCHES] WIP: bufmgr rewrite per recent discussions
(cut)
3. Pad the LWLock struct
1 - 100 of 131 matches
Mail list logo
