On 13 July 2011 01:23, Andres Freund and...@anarazel.de wrote:
On Tuesday, July 12, 2011 08:57:44 PM Dean Rasheed wrote:
On 12 July 2011 19:26, Josh Berkus j...@agliodbs.com wrote:
On 7/12/11 9:46 AM, Andres Freund wrote:
Hi,
I guess $subject wasn't implemented because plain unique
On 7 July 2011 22:34, Alvaro Herrera alvhe...@commandprompt.com 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:
* 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
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
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
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
aekorot...@gmail.comwrote:
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
2011/6/29, Florian Pflug f...@phlo.org:
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
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
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,
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
Tom Lane t...@sss.pgh.pa.us 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.
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
Dean Rasheed dean.a.rash...@gmail.com 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
Florian Pflug wrote:
On Jul11, 2011, at 17:31 , Bruce Momjian wrote:
Tom Lane wrote:
Florian Pflug f...@phlo.org 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 br...@momjian.us 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
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 harmeeksi...@gmail.com 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
On Jul13, 2011, at 17:44 , Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Florian Pflug wrote:
On Jul13, 2011, at 17:44 , Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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 have
Bruce Momjian br...@momjian.us 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
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
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 harmeeksi...@gmail.com 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
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.
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
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 of fields
On 07/13/2011 12:31 PM, Tom Lane wrote:
Bruce Momjianbr...@momjian.us 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
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 might not be
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
Andrew Dunstan wrote:
On 07/13/2011 12:31 PM, Tom Lane wrote:
Bruce Momjianbr...@momjian.us 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
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
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 same as
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's
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 that apps that
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).
Well it
David E. Wheeler da...@kineticode.com 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';$$;
On Jul 12, 2011, at 8:10 PM, Florian Pflug f...@phlo.org wrote:
On Jul13, 2011, at 00:10 , Robert Haas wrote:
On Jul 12, 2011, at 8:03 AM, Florian Pflug f...@phlo.org wrote:
The algorithm is quite straight forward, if one assumes a lock-free
implementation of a queue (More on that below)
On Jul 13, 2011, at 1:43 PM, Bruce Momjian br...@momjian.us 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 index
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 br...@momjian.us wrote:
Daniele Varrazzo wrote:
=# select extract(epoch from 'infinity'::timestamp);
date_part
---
0
A better value would be
Bruce Momjian br...@momjian.us 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
On 14 July 2011 06:58, Alvaro Herrera alvhe...@commandprompt.com 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
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
Robert Haas robertmh...@gmail.com writes:
On Jul 13, 2011, at 1:43 PM, Bruce Momjian br...@momjian.us 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
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
On Jul 13, 2011, at 4:21 PM, Brendan Jurd dire...@gmail.com wrote:
On 14 July 2011 06:58, Alvaro Herrera alvhe...@commandprompt.com 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
On 14 July 2011 08:16, Robert Haas robertmh...@gmail.com wrote:
On Jul 13, 2011, at 4:21 PM, Brendan Jurd dire...@gmail.com 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
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 one thing
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 if
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 be
On Jul13, 2011, at 22:04 , Robert Haas wrote:
On Jul 12, 2011, at 8:10 PM, Florian Pflug f...@phlo.org 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
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
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
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
On Wed, Jul 13, 2011 at 7:42 PM, Josh Berkus j...@agliodbs.com 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
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 be
62 matches
Mail list logo
