Greg,
Thanks for comments.
Greg Smith wrote:
> The idea of using pg_rusage_init is a new one though; I hadn't thought the
> CPU usage info was interesting enough to figure out how to collect it.
> The way the patch mentioned above works it would be hard to squeeze it in
> the line usefully for
2007/6/13, Alvaro Herrera <[EMAIL PROTECTED]>:
Well, more I/O numbers would be more interesting than CPU stats ...
Well, I think so too, and I attempted to print block in / out using getrusage(),
but I couldn't get them because they were always zero (on my linux).
I still can't understand the
Hi all,
Here is a brand new patch to log a checkpointing load information
to tune the bgwriter parameter.
When you enable trace_checkpoint parameter and process
the checkpoint, the bgwriter logs the number of
flushed buffer pages and the elapsed time.
Hi all,
Here is a brand new patch to log a checkpointing load information
to tune the bgwriter parameter.
When you enable trace_checkpoint parameter and process
the checkpoint, the bgwriter logs the number of
flushed buffer pages and the elapsed time.
Tom Lane wrote:
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -fpic
> -I. -I../../src/include -D_GNU_SOURCE -c -o pgstatindex.o pgstatindex.c
> pgstatindex.c: In function 'bt_page_items':
> pgstatindex.c:564
f the README.
>
> -------
>
>
> Satoshi Nagayasu wrote:
>> Bruce,
>>
>> Attached patch has been cleaned up,
>> and modified to be able to work with CVS HEAD.
>>
>> Thanks.
>>
>> Satoshi Nagayasu wrote:
&g
Sorry, I'll write README (and uninstall.sql?) by tomorrow.
Bruce Momjian wrote:
> Satoshi Nagayasu wrote:
>> Bruce,
>>
>> Bruce Momjian wrote:
>>> BTIem is no longer in CVS HEAD, though it was in 8.1.X. Please update
>>> your patch for CVS HEAD. Than
Bruce,
Bruce Momjian wrote:
> BTIem is no longer in CVS HEAD, though it was in 8.1.X. Please update
> your patch for CVS HEAD. Thanks.
I've posted CVS HEAD workable version on Aug.14.
Please check it out. Thanks.
--
NAGAYASU Satoshi <[EMAIL PROTECTED]>
Phone: +81-3-3523-8122
Bruce,
Attached patch has been cleaned up,
and modified to be able to work with CVS HEAD.
Thanks.
Satoshi Nagayasu wrote:
> Alvaro,
>
> Alvaro Herrera wrote:
>> Huh, I bet it works with 8.1.4, but it doesn't work on CVS HEAD:
>>
>> /pgsql/source/00orig/contr
Alvaro,
Alvaro Herrera wrote:
> Huh, I bet it works with 8.1.4, but it doesn't work on CVS HEAD:
>
> /pgsql/source/00orig/contrib/pgstattuple/pgstatindex.c: In function
> 'GetBTPageStatistics':
> /pgsql/source/00orig/contrib/pgstattuple/pgstatindex.c:182: error: 'BTItem'
> undeclared (first use
Hi all,
Here is a patch to add pgstatindex functions to the pgstattuple module,
which can work with 8.1.4. Please review and try it. Thanks.
Satoshi Nagayasu wrote:
> Bruce,
>
> I'll fix it in this week. Please wait a few days.
> Thanks.
>
> Bruce Momjian wrote:
>
adjustment? Thanks.
>
> -------
>
> satoshi nagayasu wrote:
>> Hi folks,
>>
>> As I said on -PATCHES, I've been working on an utility to get
>> a b-tree index information. I'm happy to introduce
>> m
Hi folks,
As I said on -PATCHES, I've been working on an utility to get
a b-tree index information. I'm happy to introduce
my new functions to you.
pgstattuple module provides a `pgstatindex()`, and other small
functions, which allow you to get b-tree internal information.
I believe this module w
Hi,
I'm working on an utility for b-tree index, called `pgstatindex`.
It reports b-tree index statistics like a pgstattuple as below.
pgbench=# \x
Expanded display is on.
pgbench=# SELECT * FROM pgstatindex('accounts_pkey1');
-[ RE
Hi folks,
I've created a patch to get following TODO item.
> * %Add ability to monitor the use of temporary sort files
This patch provides one system view (pg_stat_sorts) and
one utility function (pg_stat_get_prev_sort_size).
> snaga=# SELECT * from pg_stat_sorts;
> heap_all | index_all | datu
The message format for elog() report is cleaned up.
--
NAGAYASU Satoshi <[EMAIL PROTECTED]>
diff -cr pgsql.orig/src/backend/commands/tablecmds.c
pgsql/src/backend/commands/tablecmds.c
*** pgsql.orig/src/backend/commands/tablecmds.c 2005-06-28 14:08:54.0
+0900
--- pgsql/src/backend/comma
> This isn't really a gain in localizability because it assumes that there
> are only singular and plural forms. I do agree that plugging words like
> "enabled" or "disabled" into a string is not good style. Please read
> the message style guidelines at
> http://developer.postgresql.org/docs/pos
Alvaro Herrera wrote:
> There are a few elog() calls that should really be ereport(). Also
> this message
I've fixed to call ereport() on permission error.
>>+ elog(NOTICE, "%d trigger(s) on %s %s.",
>>+ changed,
>>+ NameStr(rel->rd_rel->relname),
>>+ e
Here is new patch with pg_dump modification.
Bruce Momjian wrote:
> I am waiting for pg_dump support for this patch.
>
> ---
>
> Satoshi Nagayasu wrote:
>
>>Bruce Momjian wrote:
>>
>>
Hi guys,
BTW, I found the work_mem is still limited to 2GB.
If we support 64bit shared memory, we also need to support
64bit work_mem.
Thanks.
--
NAGAYASU Satoshi <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 3: Have you checked our extensi
Bruce Momjian wrote:
> I am not sure what to do with this patch. It is missing dump
> capability, there is no clause to disable all triggers on a table, and
> it uses a table owner check when a super user check is required (because
> of referential integrity).
>
> Satoshi, are you still working o
Hi,
Gavin Sherry wrote:
> Hmmm.. just thinking about it for a second. I wonder if we should also
> support:
>
> ALTER TABLE DISABLE TRIGGERS
I found some RDBMSes are supporting 'DISABLE TRIGGER ALL TRIGGERS' command.
Does anyone know about the SQL99 spec?
--
NAGAYASU Satoshi <[EMAIL PROTECTED]
There is one more fix...
> + tgscan = systable_beginscan(tgrel, TriggerRelidNameIndexId, true,
> + SnapshotNow, 1,
> keys);
'1' was incorrect, must be '2'.
> + tgscan = systable_beginscan(tgrel, TriggerRelidNameIndexId, true,
>
Thanks for comments, Neil.
Some are fixed.
Neil Conway wrote:
> Also, you should probably skip the simple_heap_update() if the user
> tries to disable an already-disabled trigger, to avoid pointless MVCC
> bloat (and same for enabling an already-enabled trigger, of course).
Do we need some log
r fk) is very painful.
Christopher Kings-Lynne wrote:
>
> Satoshi Nagayasu wrote:
>
>>>The table owner can drop and create triggers - so why shouldn't they be
>>>able to enable and disable them?
>>
>>
>>For convenience or easy operation.
>>
> The table owner can drop and create triggers - so why shouldn't they be
> able to enable and disable them?
For convenience or easy operation.
I believe the user doesn't like to create same triggers again and again.
Christopher Kings-Lynne wrote:
>>>ALTER TABLE ENABLE TRIGGER
>>>ALTER TABLE
checks.
> From: Bruce Momjian
> Date: 2005/06/29 20:49
> Subject: Re: [HACKERS] Open items
> To: Satoshi Nagayasu <[EMAIL PROTECTED]>
> Cc: PostgreSQL-development
>
>
> Satoshi Nagayasu wrote:
>
>>How about enable/disable triggers?
>>
>>&
Bruce Momjian wrote:
>>It's come up a few times ... more than an un-overridable read-only mode
>>anyway. Also, I should think that those who want a secure read-only
>>mode want it enforced selectively --- for instance, assuredly read-only
>>for some users but not others. I can hardly
Satoshi Nagayasu wrote:
> I wanted to make the postmaster read-only, and found
> "default_transaction_read_only" option, but it can be overwritten.
I mean it can be overridden by the user. I don't want that.
--
NAGAYASU Satoshi <[EMAIL PROTECTED]>
OpenSource Developme
> But the second is only a subset of the first, no? So why not just
> implement the first? Put another way, why do you think the second is
> necessary?
Because there is "default_transaction_read_only" option and
implementation.
My implementation is an extension of the exist
I think the read-only has two meanings for the user.
First is the internal state. XID, OID or something like that.
In these cases, the internal state mustn't be changed.
Some users will need the read-only for internal state.
Second is read-only for the user data contents.
In
Tom Lane wrote:
> I'd view this as a postmaster state that propagates to backends.
> Probably you'd enable it by means of a postmaster option, and the
> only way to get out of it is to shut down and restart the postmaster
> without the option.
I've created a patch to make a p
32 matches
Mail list logo