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
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
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]
__
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?
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
/commands/analyze.c
plain diff against current CVS (31/07/2003 NZST)
Best wishes
Mark
696a697,702
> /*
>* emit some interesting relation info
>*/
> elog(elevel, " pages = %d rows/page = %d rows = %d",
> onerel->rd_nblocks, (int)tu
After browsing this list, I thought I would re-submit this in a more
standard form.
In addition I corrected a couple of things (integer cast for the number
of rows,
and capitalization in the comment)
regards
Mark
--- src/backend/commands/analyze.c.orig 2003-07-31 20:49:22.0 -0400
Found some bugs with this patch - that makes it about 1 per line
patched... :-(
i) onerel->rd_nblocks should be elog'ed as an unsigned int.
ii) acquire_sample_rows has 2 return points - I had ignored the case
where the
onerel has < sample size tuples in it.
--- src/backend/commands/analyz
change which makes the "enter data to be
copied..." message appear for both \copy and COPY in an interactive
setting.
If there's interest, I can build a patch against the current
development version.
- Mark
---8<--- TRIM,
I'd vote for it as a clarity factor too.
Klaus Naumann wrote:
On Tue, 20 Jul 2004 [EMAIL PROTECTED] wrote:
FATAL: unrecognized configuration parameter "archive_mode"
Have I missed something since it has been committed?
Yes, Tom has removed this option in favorite of just setting
archive_co
To add to the confusion it works for me as well - Windows 2003 with
Mingw 3.1.0
Peter Eisentraut wrote:
Magnus Hagander wrote:
Readline is pretty badly broken under mingw. Basically, it disables
the alt-gr key, which renders psql almost useless on most locales (no
way to type backslash, and a
- CVS HEAD from approx 19 Jul
- locale is 'English_New Zealand.1252'
Magnus Hagander wrote:
Hmm. And this is a cvs pull that was before Bruce actually disabled
readline? What locale are you in?
---(end of broadcast)---
TIP 5: Have you checked our e
Sorry - I have done it too:
Windows Locale is : English (New Zealand)
Mark Kirkwood wrote:
- CVS HEAD from approx 19 Jul
- locale is 'English_New Zealand.1252'
Magnus Hagander wrote:
Hmm. And this is a cvs pull that was before Bruce actually disabled
readline? What locale
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
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
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
# 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
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
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
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
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
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)--
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
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
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
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
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
--
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
-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
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
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
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
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
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
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
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
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
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
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
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
===
points into account.
Cheers
Mark
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
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
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)---
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
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
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
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
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
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
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:
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 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 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
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
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
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:
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 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
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
=
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
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
--
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
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
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
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
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
=
Sorry Bruce - I meant your 'fix for win32 pgport and pg_dumpall' patch.
Mark
Bruce Momjian wrote:
[EMAIL PROTECTED] wrote:
It was, next update got it! Of course I found the src/utils issue then
However, with the patch for that applied I can confirm a successful build!
Wha
increases the T1target,
> and since we are missing them with a too small directory size, our
> implementation of ARC is propably using a T2 size larger than the
> working set. That is not optimal.
>
> If we would replace the dynamic T1 buffers with a max_backends*2 area of
> shared buffers, use a C value representing the effective cache size and
> limit the T1target on the lower bound to effective cache size - shared
> buffers, then we basically moved the T1 cache into the OS buffers.
>
> This all only holds water, if the OS is allowed to swap out shared
> memory. And that was my initial question, how likely is it to find this
> to be true these days?
>
>
> Jan
>
I've asked our linux kernel guys some quick questions and they say
you can lock mmapped memory and sys v shared memory with mlock and
SHM_LOCK, resp. Otherwise the OS will swap out memory as it sees
fit, whether or not it's shared.
Mark
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
variables - so what better place to find examples than in the documentation!
best wishes
Mark
--- plpgsql.sgml.orig Thu Dec 2 19:07:05 2004
+++ plpgsql.sgmlThu Dec 2 21:49:55 2004
@@ -2556,6 +2556,70 @@
CREATE TRIGGER emp_stamp BEFORE INSERT OR UPDATE ON emp
FOR EACH ROW EXECUTE
Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> writes:
This patch adds another plpgsql trigger example to the chapter. It uses
the emp table again, but shows how to audit changes into another table
(emp_audit).
Should be an AFTER trigger, else you may be recording the wrong da
,
stamp timestamp NOT NULL,
useridtext NOT NULL
) INHERITS (emp);
However SELECT FROM emp will return rows from emp_audit as well! (unless
we always use FROM ONLY or set SQL_INHERITANCE=false). This seem likely
to confuse things!
regards
Mark
unfortunately
means it is longish. This made me wonder about its placement (i.e in
plpgsql examples). It could go in a 'Data warehousing' chapter - if we
had one
Any suggestions welcome.
best wishes
Mark
P.s : use is made of a schema from Ralph Kimball's "The Data Warehouse
/chapter in its own right, and include the the summary table +
trigger as an example therein.
2) Perhaps leave the trigger + plpgsql function as a plpgsql example,
and refer to it in the (new) data warehouse section/chapter.
Comments?
(BTW, These both look like 8.1 doc changes)
regards
Mark
Mark Kirkwood wrote:
2) Perhaps leave the trigger + plpgsql function as a plpgsql example,
and refer to it in the (new) data warehouse section/chapter.
Looking at option 2, it seems reasonable to add a trimmed trigger
example into the plpgsql examples section now, and leave the data
warehouse
Mark Kirkwood wrote:
Looking at option 2, it seems reasonable to add a trimmed trigger
example into the plpgsql examples section now, and leave the data
warehouse introductory stuff for its own chapter at some later stage.
Sorry about this -
A amendment so as not not require a SELECT from the
fmgr.c:1141
#2 0x403bdb80 in FunctionCall2 (flinfo=Cannot access memory at address
0x0
) at fmgr.c:1141
Over and over again, so I'll keep the backtrace short.
Mark
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please
Hmm... I don't remember specifying a datatype. I suppose whatever the
default one is. :)
I'll be happy to test again, just let me know.
Mark
On Fri, Jan 28, 2005 at 06:28:32AM +0900, ITAGAKI Takahiro wrote:
> Thanks for testing, Mark!
>
> > I gave this a try with DBT-2,
As discussed on -docs.
(Not really sure if I need to explicitly forward here)
regards
Mark
--- Begin Message ---
Tom Lane wrote:
This seems a bit awkwardly phrased:
+
+Versions before 4.0 will require a kernel rebuild, see the
+NetBSD and
+class="o
As discussed on -docs.
--- Begin Message ---
Post feedback changes - thanks to all who commented!
Mark Kirkwood wrote:
I wanted to understand how the planner 'knows' how many rows are likely
to be emitted in a given stage of a query, and wrote down some examples
for my own benefi
s'
sections quite well.
I certainly
wouldn't want to promise that a chunk of documentation like this
will stay up-to-date.
Yeah - that is a concern... no doco is better than wrong doco :-)
Mind you, ISTM that the same objection could be leveled at the 'stats'
section
best wi
).
Having said that, if it seems that this is really too much like reading
the code to be in the docs at all, then another option is for it to go
to one of the community sites (like varlena), where it could be
(reformatted) and clearly marked as relevant for 7.x and 8.0 onl
00 tps=146 (145-148)
8.1 CVS + buf patch
shared_buffers=1000 tps=135 (131-138)
shared_buffers=1 tps=154 (154-155)
regards
Mark
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
www.osdl.org/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
promising.
So about a 50% 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
activity!).
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
ative would be to not include those rows in the result set,
although perhaps administrators might want this information.)
I thought it might be handy to explicitly see unused (or belonging to
another db) buffers. Clearly joining to pg_class will project 'em out!
Finally, thanks for the excel
ere?). I am using anoncvs from 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
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
ld like this to be
a bit 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_view
ut the flags?
In addition Tom pointed out that I am not examining 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 N
fercache'. Some 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 re
' 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
--
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
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
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 -
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
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
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
-
1 - 100 of 152 matches
Mail list logo
