On 13 July 2011 01:23, Andres Freund wrote:
> On Tuesday, July 12, 2011 08:57:44 PM Dean Rasheed wrote:
>> On 12 July 2011 19:26, Josh Berkus wrote:
>> > On 7/12/11 9:46 AM, Andres Freund wrote:
>> >> Hi,
>> >>
>> >> I guess $subject wasn't implemented because plain unique indexes aren't
>> >> re
On 7 July 2011 22:34, Alvaro Herrera wrote:
> Hi,
>
> The attached patch introduces pg_constraint rows for NOT NULL
> column constraints.
>
> This patch is a heavily reworked version of Bernd Helmle's patch here:
> http://archives.postgresql.org/message-id/E57A252DFD60C1FCA91731BD@amenophis
>
> I
* Alvaro Herrera wrote:
[ ... looks some more ... ] Oh, it seems inconsistent. Several hosts
do not run it at all; chinchilla and anchovy are running the wrong make
target; but at least chough seems to be doing it right. Crake is good
too.
chinchilla and jaguarundi are now running the buil
Hi,
Looking at the performance test results again on the wiki page
(http://wiki.postgresql.org/wiki/Fast_GiST_index_build_GSoC_2011#Testing_results),
the patch can be summarized like this: it reduces the number of disk
accesses, at the cost of some extra CPU work.
Is it possible to switch to
On Tue, 12 Jul 2011 11:11:40 -0700, Josh Berkus wrote:
Radoslaw,
For me this discussion is over. I putted my objections and
suggestions. Full
review is available in archives, and why to not escape is putted in
review
of your 2nd patch, about scalar values.
Did you install and test the funct
Hi!
On Wed, Jul 13, 2011 at 12:33 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> Is it possible to switch to the new buffering method in the middle of an
> index build? We could use the plain insertion method until the index grows
> to a certain size (effective_cache_size?
On Wed, Jul 13, 2011 at 12:40 PM, Alexander Korotkov
wrote:
> On Wed, Jul 13, 2011 at 12:33 PM, Heikki Linnakangas <
> heikki.linnakan...@enterprisedb.com> wrote:
>
>> Is it possible to switch to the new buffering method in the middle of an
>> index build? We could use the plain insertion method u
2011/6/29, Florian Pflug :
> Secondly, there is little point in having an type XML if we
> don't actually ensure that values of that type can only contain
> well-formed XML.
+1. The fact that XPATH() must return a type that cannot depend on the
given expression (even if it is a constant string) m
On 07/13/2011 04:22 AM, Christian Ullrich wrote:
* Alvaro Herrera wrote:
[ ... looks some more ... ] Oh, it seems inconsistent. Several hosts
do not run it at all; chinchilla and anchovy are running the wrong make
target; but at least chough seems to be doing it right. Crake is good
too.
On 07/13/2011 01:27 AM, Alvaro Herrera wrote:
Excerpts from Alvaro Herrera's message of mié jul 13 01:11:41 -0400 2011:
Blind attempt at fixing isolation_tester on Win32
If this doesn't work, I'm afraid I'll have to ask some Windows person
for help :-)
It appears to have worked.
cheers
an
Um, Although I have not caught up with this thread.
Ralf-san and the member of OSSP are maintaining OSSP continuously.
I think that a reaction can merely be obtained in the intervals of when
busy. Please do not need fast response.
(2011/07/13 11:35), David E. Wheeler wrote:
On Jul 12, 2011, a
On 12.07.2011 11:34, Alexander Korotkov wrote:
New version of patch with a little more refactoring and comments.
Great! The README helps tremendously to understand this, thanks for that.
One thing that caught my eye is that when you empty a buffer, you load
the entire subtree below that buffe
Tom Lane wrote:
> Another thing that struck me while looking at the code is that the
> curpages clamp is applied to indexes too, which seems like a
> thinko. A table occupying a few pages wouldn't likely have an
> index as big as the table itself is.
But not zero pages, either.
> So what I'm
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Another thing that struck me while looking at the code is that the
>> curpages clamp is applied to indexes too, which seems like a
>> thinko. A table occupying a few pages wouldn't likely have an
>> index as big as the table itself is.
> But not zer
Dean Rasheed writes:
>>> On 7/12/11 9:46 AM, Andres Freund wrote:
I guess $subject wasn't implemented because plain unique indexes aren't
represented in pg_constraint and thus do not have a place to store
information about being deferred?
> I agree that expressing that using a UNIQ
Florian Pflug wrote:
> On Jul11, 2011, at 17:31 , Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Florian Pflug writes:
> >>> On Jul11, 2011, at 17:11 , Tom Lane wrote:
> Yeah, I think this patch is going in the wrong direction altogether.
> It would be better to modify the description of
Bruce Momjian writes:
> OK, I went with this wording, using "lock object is on" terminology.
> Applied patch attached --- adjustments welcomed.
I think you misunderstood the suggestion. This is not an improvement,
it's just more confusion.
regards, tom lane
--
Sent vi
Hi tom .
Thanks for your input . Appreciate your taking time and responding . Just
some comments.
1. May be I am mistaken Kindly help me understand a bit more. I do agree
that passing datums up the node chain helps - but consider the case when
either Sort or Hash joins spills on disk -
HarmeekSingh Bedi writes:
>1. May be I am mistaken Kindly help me understand a bit more. I do agree
>that passing datums up the node chain helps - but consider the case when
>either Sort or Hash joins spills on disk - large columns that get written
> on
>to the disk will still ca
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, I went with this wording, using "lock object is on" terminology.
> > Applied patch attached --- adjustments welcomed.
>
> I think you misunderstood the suggestion. This is not an improvement,
> it's just more confusion.
Well, I thought the "lock
On Jul13, 2011, at 17:44 , Tom Lane wrote:
> Bruce Momjian writes:
>> OK, I went with this wording, using "lock object is on" terminology.
>> Applied patch attached --- adjustments welcomed.
>
> I think you misunderstood the suggestion. This is not an improvement,
> it's just more confusion.
F
Florian Pflug wrote:
> On Jul13, 2011, at 17:44 , Tom Lane wrote:
> > Bruce Momjian writes:
> >> OK, I went with this wording, using "lock object is on" terminology.
> >> Applied patch attached --- adjustments welcomed.
> >
> > I think you misunderstood the suggestion. This is not an improvemen
On Jul 13, 2011, at 6:44 AM, Hiroshi Saito wrote:
> Um, Although I have not caught up with this thread.
>
> Ralf-san and the member of OSSP are maintaining OSSP continuously.
> I think that a reaction can merely be obtained in the intervals of when busy.
> Please do not need fast response.
I ha
Bruce Momjian writes:
> Tom Lane wrote:
>> I think you misunderstood the suggestion. This is not an improvement,
>> it's just more confusion.
> Well, I thought the "lock on" wording helped avoid the confusion but
> obviously I didn't understand more than that. We did have similar
> confusion wh
On 10.07.2011 21:43, Josh Berkus wrote:
Teodor, Oleg, Heikki,
My concern is that I am unable to prove to myself simply by reading
the code that the 24 line chunk deleted from gistFindPath (near ***
919,947 ) are no longer needed. My familiarity with the gist code
is low enough that it is n
Hackers,
With regard to this change:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5f7b58fad8f45c69bb67944779dce67e2f481995
I'm wondering if it would be possible to restore the relistemp column to
pg_class, at least for backwards compatibility, so that apps that expected
I wrote:
> HarmeekSingh Bedi writes:
>> I did make a fix at least to alleviate this case in the optimizer . But I am
>> going to work on a more general approach of expression pruning based on the
>> lifetime of an expression. Basically each node will either references or
>> generate an expression.
On 7/12/11 2:05 PM, Fernando Acosta Torrelly wrote:
> Hi everybody:
>
>
>
> Does anybody has an example to send an email in html format using pgmail.
Please send your question to the pgmail mailing list. Nobody on
pgsql-hackers can answer it.
--
Josh Berkus
PostgreSQL Experts Inc.
http://
On 30.06.2011 07:50, Jeff Janes wrote:
My concern is that I am unable to prove to myself simply by reading
the code that the 24 line chunk deleted from gistFindPath (near ***
919,947 ) are no longer needed. My familiarity with the gist code
is low enough that it is not surprising that I cann
Daniele Varrazzo wrote:
> Hello,
>
> =# select extract(epoch from 'infinity'::timestamp);
> date_part
> ---
> 0
>
> A better value would be 'infinity'::float8. Ditto for -infinity.
>
> I'm trying to use a box-based index to represent the intervals in a
> table containing a pair
On 07/13/2011 12:31 PM, Tom Lane wrote:
Bruce Momjian writes:
Tom Lane wrote:
I think you misunderstood the suggestion. This is not an improvement,
it's just more confusion.
Well, I thought the "lock on" wording helped avoid the confusion but
obviously I didn't understand more than that.
Thank you very much for detail explanation. But this line of modified patch
seems strange for me:
*newchildoffnum = blkno;
I believe it should be:
*newchildoffnum = i;
--
With best regards,
Alexander Korotkov.
Florian Pflug wrote:
> We could also get rid of the noun completely by saying
>
> (D)
> "Locked page number within the relation, or null if it isn't
>a tuple or relation page that is locked".
>
> I personally slightly favor (D).
I don't think we can use "Locked" here because the lock mig
On 13.07.2011 21:56, Alexander Korotkov wrote:
Thank you very much for detail explanation. But this line of modified patch
seems strange for me:
*newchildoffnum = blkno;
I believe it should be:
*newchildoffnum = i;
Yes, you're right. It's scary that it worked during testing anyway.
Maybe the r
Andrew Dunstan wrote:
>
>
> On 07/13/2011 12:31 PM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> Tom Lane wrote:
> >>> I think you misunderstood the suggestion. This is not an improvement,
> >>> it's just more confusion.
> >> Well, I thought the "lock on" wording helped avoid the confusion bu
Tom Lane wrote:
> Another reason not to rely completely on the auto-analyze update path is
> that it doesn't work for temp tables, since autovac can't access another
> session's temp tables. It's also worth noting that auto-analyze will
> never kick in at all for tables of less than about 60 rows,
David E. Wheeler wrote:
> Hackers,
>
> With regard to this change:
>
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5f7b58fad8f45c69bb67944779dce67e2f481995
>
> I'm wondering if it would be possible to restore the relistemp column
> to pg_class, at least for backwards c
On Jul 13, 2011, at 12:14 PM, Bruce Momjian wrote:
>> I'm wondering if it would be possible to restore the relistemp column
>> to pg_class, at least for backwards compatibility, so that apps that
>> expected it can continue to work on both 9.0 and 9.1. Even if it's
>> read-only somehow, and the sa
David E. Wheeler wrote:
> On Jul 13, 2011, at 12:14 PM, Bruce Momjian wrote:
>
> >> I'm wondering if it would be possible to restore the relistemp column
> >> to pg_class, at least for backwards compatibility, so that apps that
> >> expected it can continue to work on both 9.0 and 9.1. Even if it'
Excerpts from Bruce Momjian's message of mié jul 13 15:24:35 -0400 2011:
> David E. Wheeler wrote:
> > On Jul 13, 2011, at 12:14 PM, Bruce Momjian wrote:
> >
> > >> I'm wondering if it would be possible to restore the relistemp column
> > >> to pg_class, at least for backwards compatibility, so th
On Jul 13, 2011, at 12:38 PM, Alvaro Herrera wrote:
>> Well, that assumes people read the documention and don't just do \d.
>> Keeping cruft around over time makes the system more complex.
>
> This seems a case where column synonyms would have been useful (as was
> the procpid / pid change).
Wel
"David E. Wheeler" wrote:
> Unless you could make a kind of "view column" or something where the
> expression was `relpersistence <> 't'`.
create or replace function relistemp(rel pg_class)
returns boolean language sql immutable strict as
$$select $1.relpersistence = 't';$$;
Just don't
On Jul 12, 2011, at 8:10 PM, Florian Pflug wrote:
> On Jul13, 2011, at 00:10 , Robert Haas wrote:
>> On Jul 12, 2011, at 8:03 AM, Florian Pflug wrote:
>>> The algorithm is quite straight forward, if one assumes a lock-free
>>> implementation of a queue (More on that below)
>>
>> This is similar
On Jul 13, 2011, at 1:43 PM, Bruce Momjian wrote:
> Daniele Varrazzo wrote:
>> Hello,
>>
>> =# select extract(epoch from 'infinity'::timestamp);
>> date_part
>> ---
>> 0
>>
>> A better value would be 'infinity'::float8. Ditto for -infinity.
>>
>> I'm trying to use a box-based in
Excerpts from Robert Haas's message of mié jul 13 16:13:12 -0400 2011:
> On Jul 13, 2011, at 1:43 PM, Bruce Momjian wrote:
> > Daniele Varrazzo wrote:
> >> =# select extract(epoch from 'infinity'::timestamp);
> >> date_part
> >> ---
> >> 0
> >>
> >> A better value would be 'infin
Bruce Momjian writes:
> Tom Lane wrote:
>> Another reason not to rely completely on the auto-analyze update path is
>> that it doesn't work for temp tables, since autovac can't access another
>> session's temp tables. It's also worth noting that auto-analyze will
>> never kick in at all for table
On 14 July 2011 06:58, Alvaro Herrera wrote:
> I don't find the proposed behavior all that suprising, which the
> original behavior surely is. I guess the bigger question is whether the
> values that timestamptz_part() returns for other cases (than epoch)
> should also be different from 0 when an
> It's sort of non-obvious that either behavior is better than the other.
Here's the reason why the existing behavior is wrong:
postgres=# select extract('epoch' from timestamptz 'infinity') = extract
('epoch' from timestamptz '1970-01-01 00:00:00-00');
?column?
--
t
--
Josh Berkus
P
Robert Haas writes:
> On Jul 13, 2011, at 1:43 PM, Bruce Momjian wrote:
>> I see:
>>
>> if (TIMESTAMP_NOT_FINITE(timestamp))
>> {
>> result = 0;
>> PG_RETURN_FLOAT8(result);
>> }
>>
>> Does anyone object to changing this?
> It's sort of non-obvious that either behavior is better than
Attached is patch for the WAL writer that removes its tight polling
loop (which probably doesn't get hit often in practice, as we just
sleep if wal_writer_delay is under a second), and, at least
potentially, reduces power consumption when idle by using a latch.
I will break all remaining power con
On Jul 13, 2011, at 4:21 PM, Brendan Jurd wrote:
> On 14 July 2011 06:58, Alvaro Herrera wrote:
>> I don't find the proposed behavior all that suprising, which the
>> original behavior surely is. I guess the bigger question is whether the
>> values that timestamptz_part() returns for other cases
On 14 July 2011 08:16, Robert Haas wrote:
> On Jul 13, 2011, at 4:21 PM, Brendan Jurd wrote:
>> Well, for example, how do you go about answering the question "what is
>> the day-of-month of the infinite timestamp?" The question is
>> nonsense; it doesn't have a defined day of month, so I think w
Excerpts from Alexey Kluykin's message of mar jun 21 07:43:02 -0400 2011:
> > Another benefit of removing the check is that it reduces code complexity.
> > Maybe
> > not when measured in line counts, but it's one less outside factor that
> > changes
> > ProcessConfigFiles()'s behaviour and thus
On Jul13, 2011, at 21:08 , Bruce Momjian wrote:
> - OID of the database in which the object exists, or
> - zero if the object is a shared object, or
> - null if the lock object is on a transaction ID
> + OID of the database in which the lock target exists, or
> + zero
On Jul14, 2011, at 01:38 , Alvaro Herrera wrote:
> One strange thing here is that you could get two such messages; say if a
> file has 100 parse errors and there are also valid lines that contain
> bogus settings (foo = bar). I don't find this to be too problematic,
> and I think fixing it would b
On Jul13, 2011, at 22:04 , Robert Haas wrote:
> On Jul 12, 2011, at 8:10 PM, Florian Pflug wrote:
>> I wonder if clearing the waiters-present bit only upon clearing the
>> queue completely is necessary for correctness. Wouldn't it be OK
>> to clear the bit after waking up at least one locker? That
All,
We're almost at the end of the CommitFest, and three patches have not
yet been reviewed:
lazy vxid locks
https://commitfest.postgresql.org/action/patch_view?id=585
sepgsql - userspace access vector cache
https://commitfest.postgresql.org/action/patch_view?id=578
Allow multiple Postgres clu
I would like to volunteer for the last one:
> Add ability to constrain backend temporary file space
> https://commitfest.postgresql.org/action/patch_view?id=533
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-h
On Jul14, 2011, at 02:42 , Josh Berkus wrote:
> lazy vxid locks
> https://commitfest.postgresql.org/action/patch_view?id=585
I can try to review that. It does seems to depend on
the fastlock patch though, and that patch seems to be
somewhat of a moving target. I'm thus not sure what the
most reaso
On Wed, Jul 13, 2011 at 7:42 PM, Josh Berkus wrote:
> All,
>
> We're almost at the end of the CommitFest, and three patches have not
> yet been reviewed:
>
> lazy vxid locks
> https://commitfest.postgresql.org/action/patch_view?id=585
>
> sepgsql - userspace access vector cache
> https://commitfes
Excerpts from Florian Pflug's message of mié jul 13 20:12:28 -0400 2011:
> On Jul14, 2011, at 01:38 , Alvaro Herrera wrote:
> > One strange thing here is that you could get two such messages; say if a
> > file has 100 parse errors and there are also valid lines that contain
> > bogus settings (foo
On Thu, 2011-07-14 at 02:54 +0200, Florian Pflug wrote:
> On Jul14, 2011, at 02:42 , Josh Berkus wrote:
> > lazy vxid locks
> > https://commitfest.postgresql.org/action/patch_view?id=585
>
> I can try to review that. It does seems to depend on
> the fastlock patch though, and that patch seems to b
On Tue, 2011-07-05 at 13:15 -0400, Robert Haas wrote:
> On Tue, Jul 5, 2011 at 1:13 PM, Robert Haas wrote:
> > Here is an updated version of the "lazy vxid locks" patch [1], which
> > applies over the latest "reduce the overhead of frequent table
> > locks"[2] patch.
> >
> > [1] https://commitfest
> Hackers,
>
> This patch needs a new reviewer, per Cedric. Please help!
Hi I am the new reviewer:-)
I have looked into the v6 patches. One thing I would like to suggest
is, enhancing the error message when temp_file_limit will be exceeded.
ERROR: aborting due to exceeding temp file limit
Is
64 matches
Mail list logo
