ly 3 if we use a fork for the
visibility map). 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
procedures to implement my own recursion. :-)
Cheers,
mark
--
Mark Mielke <[EMAIL PROTECTED]>
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 ther
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 vi
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
> > > BL
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
est
correctness.
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
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 is
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
ather hacky patch seems to cure the behaviour - 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
==
Alvaro Herrera wrote:
Mark Kirkwood wrote:
Alvaro Herrera wrote:
Except that it also includes diffs for generated files, which tend to be
huge. To work around that you need to create a list of files to
exclude, and the whole thing (which was cumbersome already) starts to
get unmanageable
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 us
-Nacr 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 run
s.
The second approach seems 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
--
32 78 s 155 MB/s
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 loca
HOT-update chain. 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 co
erl function works fast enough
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
st - so I looked back at the
older postgres versions (e.g. 7.1.3) 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
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 ad
more.
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)--
ls silly
adding -DLINUX_PROFILE on Freebsd! (maybe just PROFILE or GPROF_PROFILE?).
Cheers
Mark
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ugh.
Little typo:
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
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 gp
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 row
# select avg(val2) from avgtest;
avg
-
714285.21428580
(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
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
the new
accumulators for avg(int8|numeric).
- Adds the new accumulators into the bootstrap entries for pg_proc.
Performance gain is approx 33% (it is still slower than doing sum/count
- possibly due to the construct/deconstruct overhead of the numeric
transition array).
Cheers
Mark
Index
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
x27;ll spend some time on making those changes a bit more
refined.
Kind regards,
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
he two range table entry
types 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/
rement from this point forward through the clock sequence values
until real time catches up. An alternative would be along the lines of
a /dev/uuid device, that like /dev/random, would be responsible for
outputting unique uuid values for the system. Who does this?
wards.
Which standard UUID generation function would you be thinking of?
Inventing a new one doesn't seem sensible. I'll have to read over the
versions again...
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
routines.
I would not use a 100% random number generator for a UUID value as was
suggested. I prefer inserting the MAC address and the time, to at
least allow me to control if a collision is possible. This is not easy
to do using a few lines of C code. I'd rather have a UUID type in core
wit
ined is better when not in control.
The only thing an in-core version provides is convenience for those
that do not have easy access to a UUID generation library. I don't
care for that convenience.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PR
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://arch
).
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
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
that do
have useful amounts of free space.
Maybe an overloaded pgstattuple function that allows you to request FSM
behavior?
That's a nice idea - could also do equivalently by adding an extra
column "usable_free_space" or some such, and calculating this using FSM
l
riate data.
Ok - I did 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
I would have 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
--
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
ir test cases
are not sensitive to the particular 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
=
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 mo
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
co
Mark Kirkwood wrote:
Come to think of it, what are the appropriate OS's? (I see
NetBSD mentioned so I suppose all the *BSDs, but what others?).
FWIW FreeBSD (6.0) does *not* have posix_fadvise, only posix_madvise.
regards
Mark
---(end of broa
Tom Lane wrote:
Bruce Momjian 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 for ensuring it never will be
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
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 on
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 of the
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 the
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
ts).
BTW - Nice to see someone reading this... :-)
Best wishes
Mark
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
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
most effective change to make (thinking
back to last two TODOs that I tackled - it was quite difficult to find
the mail thread(s) containing the details).
regards
Mark
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore
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
Not wanting to denigrate
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
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
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 broadcast)---
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 sta
points into account.
Cheers
Mark
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
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
===
7;=' operator in
pg_operator.h.
with the patch applied, all 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
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 subin
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.
> >
> > H
g/projects/dbt2dev/results/dev4-015/38/
5462.23 notpm
Would it help more to try a series of parameter changes?
Mark
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
air performance 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/
4
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
FreeBSD 5.4 RELEASE gcc 3.4.2 on Intel dual PIII 1Ghz
[postgres:~/develop/c/testbuf]$ gcc -Wall -o testbuf testbuf.c
[postgres:~/develop/c/testbuf]$ ./testbuf
duration round 1 of array method: 1.737 ms
duration round 2 of array method: 1.676 ms
duration round 3 of array method: 1.527 ms
duration
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.
N
4-way 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 da
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 (
00 customer.tbl
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:
TEXT format parsing). So now
> TEXT,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
intere
Hi,
I grabbed the patches to try, but I was wondering if it would be more
interesting to try them against CVS rather than 8.0.3 (and if it would
be easy to port :)?
Mark
---(end of broadcast)---
TIP 4: Have you searched our list archives
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 u
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
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 abou
y.
BTW - Bruce, I like the changes, makes the beast 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
d
Also, 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
e problem. Not sure if there would 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)---
TI
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 ./do
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 VARSIZ
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
g a column's storage from MAIN -> EXTENDED 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
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:
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 a
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
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!
r
regression=# set 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]
#x27;t really
think 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 wi
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
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
0, wal_buffers=256,
>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
-
atch should sort 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_bufferc
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/Mak
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 -
as a contrib 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
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
1 - 100 of 152 matches
Mail list logo
