Am Dienstag, 18. Juli 2006 23:44 schrieb Zdenek Kotala:
> I added additional comments marked setting which need server restart to
> take effect. I use (!RSR!) tag for it, however if anybody have different
> idea, let me know and I will change it.
It seems that people didn't like introducing secret
Peter Eisentraut wrote:
Am Dienstag, 18. Juli 2006 23:44 schrieb Zdenek Kotala:
I added additional comments marked setting which need server restart to
take effect. I use (!RSR!) tag for it, however if anybody have different
idea, let me know and I will change it.
It seems that people didn't l
Am Montag, 24. Juli 2006 12:25 schrieb Zdenek Kotala:
> OK, I going to change. Is there any limit to char per line?
It's already committed.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 1: if posting/rea
Peter Eisentraut wrote:
Am Montag, 24. Juli 2006 12:25 schrieb Zdenek Kotala:
OK, I going to change. Is there any limit to char per line?
It's already committed.
Oh, excellent. Thanks
---(end of broadcast)---
TIP 1: if posting/reading throug
Zdenek,
On Fri, Jul 14, 2006 at 12:17:55AM +0200, Zdenek Kotala wrote:
> There is last version of patch with following changes/improvements:
> 1) I divide set_config_option to more smaller functions without backside
> effect.
I did not check the changes you have done to set_config_option and th
Hello Pavel,
On Mon, 24 Jul 2006, Pavel Stehule wrote:
Hello,
I looked on your patch. I didn't test it, but I see so you use transmit
array, not record what I expect. Why?
If you mean that the state types (the values returned by the transition
functions) are arrays and cannot be records, t
Any chance that my LDAP patch
http://momjian.us/mhonarc/patches/msg0.html
will get reviewed before the feature freeze?
Yours,
Laurenz Albe
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subsc
ITAGAKI Takahiro wrote:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > >> Also, I added an experimental feature for btree indexes. It checks
> > >> fragmentation factor of indexes.
>
> > The really serious problem with reporting this info via NOTICE is that
> > there's no way for a program to get it
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> ITAGAKI Takahiro wrote:
>> BTW, should we change VACUUM VERBOSE in the same way? If we do so,
>> autovacuum can handle the reports of VACUUM VERBOSE and plan when to
>> do VACUUM FULL, REINDEX and/or CLUSTER using the information.
>> Is this worth doing?
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Any chance that my LDAP patch
> http://momjian.us/mhonarc/patches/msg0.html
> will get reviewed before the feature freeze?
Feature freeze is the deadline for patch submission, not patch application.
regards, tom lane
--
Joachim Wieland <[EMAIL PROTECTED]> writes:
> I did not check the changes you have done to set_config_option and the like
> but tested the commenting / uncommenting / changing of guc variables and the
> behavior and log output. The general idea (at least my idea) is that
> whenever a SIGHUP is rece
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> Since the feature freeze is in a few days, I'm sending the first iteration
> of my patch implementing the multi-argument aggregates (PolyArgAgg) (SOC
> project)
This patch is nowhere near ready for submission :-(. Most of the
comments seem to be
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Joachim Wieland <[EMAIL PROTECTED]> writes:
> > I did not check the changes you have done to set_config_option and the like
> > but tested the commenting / uncommenting / changing of guc variables and the
> > behavior and log output. The general idea (at leas
On Mon, 24 Jul 2006, Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
Since the feature freeze is in a few days, I'm sending the first iteration
of my patch implementing the multi-argument aggregates (PolyArgAgg) (SOC
project)
This patch is nowhere near ready for submission :-(
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There are basically two ways you could go about this:
>> 1. Make a new jointree leaf node type to represent a VALUES construct,
>> and dangle the list of lists of expressions off that.
>> 2. Make a new RangeTblEntry type to represent a VAL
Tom Lane wrote:
There are basically two ways you could go about this:
1. Make a new jointree leaf node type to represent a VALUES construct,
and dangle the list of lists of expressions off that.
2. Make a new RangeTblEntry type to represent a VALUES construct, and
just put a RangeTblRef to it i
Joe Conway <[EMAIL PROTECTED]> writes:
> Good feedback -- thanks! But without the RTE, how would VALUES in the
> FROM clause work?
Is it different from INSERT? I'm just imagining a Values node in
the jointree and nothing in the rangetable.
If I'm reading the spec correctly, VALUES is exactly pa
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> This is a revised patch originated by Junji TERAMOTO for HEAD.
> [BTree vacuum before page splitting]
> http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php
> I think we can resurrect his idea because we will scan btree pages
> at-atim
Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost:
> #2: That variable can *not* be changed by a reload.
> Notice-level message is sent to the log notifying the admin that the
> change requested could not be performed.
This already happens.
--
Peter Eisentraut
http://developer.postg
On Mon, Jul 24, 2006 at 07:09:17PM +0200, Peter Eisentraut wrote:
> Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost:
> > #2: That variable can *not* be changed by a reload.
> > Notice-level message is sent to the log notifying the admin that the
> > change requested could not be perfor
On Mon, Jul 24, 2006 at 10:55:47AM -0400, Stephen Frost wrote:
> #2: That variable can *not* be changed by a reload.
> Notice-level message is sent to the log notifying the admin that the
> change requested could not be performed. This change could be
> either a revert to reset-val
I just received this (offlist), and have not had a chance to review it
myself yet, but figured I should post it now in case others want to have
a look and comment or discuss before feature freeze.
If there are no major objections to the concept, I'll take
responsibility to review and commit once
Joachim Wieland wrote:
> On Mon, Jul 24, 2006 at 07:09:17PM +0200, Peter Eisentraut wrote:
> > Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost:
> > > #2: That variable can *not* be changed by a reload.
> > > Notice-level message is sent to the log notifying the admin
> > > that the change
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hannu Krossing asked me about his patch to ignore transactions running
> VACUUM LAZY in other vacuum transactions. I attach a version of the
> patch updated to the current sources.
nonInVacuumXmin seems useless ... perhaps a vestige of some earlier
ver
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Hannu Krossing asked me about his patch to ignore transactions running
> > VACUUM LAZY in other vacuum transactions. I attach a version of the
> > patch updated to the current sources.
>
> nonInVacuumXmin seems useless ... perhaps a
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> A possible objection to this is that it would foreclose running VACUUM
>> and ANALYZE as a single transaction, exactly because of the point that
>> we couldn't insert pg_statistic rows using a lazy vacuum's XID.
> Hmm, what about havi
On Mon, 24 Jul 2006, Tom Lane wrote:
Personally I don't think retail vacuuming in that form will ever fly
anyway, so I have no problem with installing the proposed patch,
but I thought I'd better throw this comment out to see if anyone
thinks it's a big deal.
My feeling is that retail vacuumin
Tom Lane wrote:
ISTM that this should be represented using an RTE_SUBQUERY node in the
outer query; the alias attaches to that node, not to the VALUES itself.
So I don't think you need that alias field in the jointree entry either.
If we stick with the plan of representing VALUES as if it were S
Cc: pgsql-hackers removed, as this mail contains a patch.
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Hannu Krossing asked me about his patch to ignore transactions running
> > VACUUM LAZY in other vacuum transactions. I attach a version of the
> > patch updated to the curren
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
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
IT
Tom Lane wrote:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> > This is a revised patch originated by Junji TERAMOTO for HEAD.
> > [BTree vacuum before page splitting]
> > http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php
> > I think we can resurrect his idea because we will
Satoshi Nagayasu wrote:
> 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 *
Tom Lane wrote:
> "Albe Laurenz" <[EMAIL PROTECTED]> writes:
> > Any chance that my LDAP patch
> > http://momjian.us/mhonarc/patches/msg0.html
> > will get reviewed before the feature freeze?
>
> Feature freeze is the deadline for patch submission, not patch application.
Right, and it will be
Satoshi Nagayasu wrote:
> Hi,
>
> I'm working on an utility for b-tree index, called `pgstatindex`.
Does it make sense to merge the pgstatindex stuff with pgstattuple, and
have the fragmentation report into pgstatindex instead of pgstattuple
itself?
--
Alvaro Herrera
"Joachim Wieland" <[EMAIL PROTECTED]> writes:
> Here's the patch that generalizes the australian_timezones hack by moving the
> compiled-in time zone definitions into a text file. The text file to use is
> chosen via a guc.
Applied with some revisions --- mostly, that I didn't like restricting
ti
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Satoshi Nagayasu wrote:
> > I'm working on an utility for b-tree index, called `pgstatindex`.
>
> Does it make sense to merge the pgstatindex stuff with pgstattuple, and
> have the fragmentation report into pgstatindex instead of pgstattuple
> itself?
I sent this patch already.
Can somebody verify this patch?
Thanks
Dhanaraj
--- Begin Message ---
I have made the changes appropriately. The regression tests passed.
Since I do not have enough resources, I could not test for a large number.
It works for a small table. If anybody tests for int8 va
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Do we add pgstatindex as a new contrib module,
> or merge it into contrib/pgstattuple?
I believe Alvaro was suggesting that you should add it as an additional
SQL function within contrib/pgstattuple. That'd be my advice too ---
I don't see a reason t
39 matches
Mail list logo
