On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
On fre, 2011-03-11 at 12:50 -0500, Bruce Momjian wrote:
It has bothered me that many of our time routines use special magic
constants for time values, e.g. 24, 12, 60, etc.
The attached patch changes these magic constants to
On Fri, 2011-03-11 at 20:44 -0500, Bruce Momjian wrote:
Looking at the code, it seems we create shared invalidation messages for
temporary table activity? Is this true? Should we be avoiding it?
I tested this by reviewing the code and checking calls to
CacheInvalidateHeapTuple(), which
On Fri, Mar 11, 2011 at 15:36, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-03-10 at 22:45 +0100, Magnus Hagander wrote:
On Thu, Mar 10, 2011 at 22:22, Bruce Momjian br...@momjian.us wrote:
Added to TODO:
Rename unix domain socket 'ident' connections to 'peer', to avoid
On Fri, Mar 11, 2011 at 16:19, Bruce Momjian br...@momjian.us wrote:
Magnus Hagander wrote:
On Fri, Mar 4, 2011 at 15:23, Yeb Havinga yebhavi...@gmail.com wrote:
On 2011-02-18 11:02, Magnus Hagander wrote:
Better late than never (or?), here's the final cleanup of
pg_streamrecv for moving
In looking at the peer patch, I notice that initdb still supports
things like -A ident map=foo, but it *only* supports this for ident,
and nothing else. I'm pretty sure this is a leftover from the ident
sameuser days, so that things like the RPM install could set it
properly. Since this is not
On Mon, 2011-03-14 at 10:28 +0100, Magnus Hagander wrote:
In looking at the peer patch, I notice that initdb still supports
things like -A ident map=foo, but it *only* supports this for ident,
and nothing else. I'm pretty sure this is a leftover from the ident
sameuser days, so that things
On 12.03.2011 12:40, Noah Misch wrote:
The installation that inspired my original report recently upgraded from 9.0.1
to 9.0.3, and your fix did significantly decrease its conflict frequency. The
last several conflicts I have captured involve XLOG_BTREE_REUSE_PAGE records.
(FWIW, the index has
Simon Riggs wrote:
On Fri, 2011-03-11 at 20:44 -0500, Bruce Momjian wrote:
Looking at the code, it seems we create shared invalidation messages for
temporary table activity? Is this true? Should we be avoiding it?
I tested this by reviewing the code and checking calls to
On Mon, Mar 14, 2011 at 4:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
On fre, 2011-03-11 at 12:50 -0500, Bruce Momjian wrote:
It has bothered me that many of our time routines use special magic
constants for time values, e.g. 24,
On Mon, Mar 14, 2011 at 8:42 AM, Bruce Momjian br...@momjian.us wrote:
Simon Riggs wrote:
On Fri, 2011-03-11 at 20:44 -0500, Bruce Momjian wrote:
Looking at the code, it seems we create shared invalidation messages for
temporary table activity? Is this true? Should we be avoiding it?
I
On Mon, Mar 14, 2011 at 5:18 AM, Magnus Hagander mag...@hagander.net wrote:
On Fri, Mar 11, 2011 at 15:36, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-03-10 at 22:45 +0100, Magnus Hagander wrote:
On Thu, Mar 10, 2011 at 22:22, Bruce Momjian br...@momjian.us wrote:
Added to TODO:
On Mon, Mar 14, 2011 at 14:43, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 14, 2011 at 5:18 AM, Magnus Hagander mag...@hagander.net wrote:
On Fri, Mar 11, 2011 at 15:36, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-03-10 at 22:45 +0100, Magnus Hagander wrote:
On Thu, Mar 10,
On 03/14/2011 09:25 AM, Robert Haas wrote:
On Mon, Mar 14, 2011 at 4:22 AM, Simon Riggssi...@2ndquadrant.com wrote:
On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
On fre, 2011-03-11 at 12:50 -0500, Bruce Momjian wrote:
It has bothered me that many of our time routines use
On Fri, Mar 11, 2011 at 8:07 PM, Bruce Momjian br...@momjian.us wrote:
Currently, if you create a temporary table with the ON COMMIT action of
DELETE ROWS, the table will truncated for every commit, whether there is
any data in the table or not.
I measured the overhead using this test:
On Sat, Mar 12, 2011 at 12:56 AM, Bruce Momjian br...@momjian.us wrote:
Presumably the point of deprecating the feature is that we'd
eventually remove it. If 4 major releases isn't long enough, what is?
Good point.
Unless there are further objections, I think we should go ahead and remove
Excerpts from Joshua D. Drake's message of dom mar 13 23:20:01 -0300 2011:
On Sun, 2011-03-13 at 19:40 -0400, Tom Lane wrote:
I'm not planning to do anything about this idea right now, since I'm
still hip-deep in collations, but I thought I'd throw it out to get
it on the record.
On 14.03.2011 16:09, Alvaro Herrera wrote:
Excerpts from Joshua D. Drake's message of dom mar 13 23:20:01 -0300 2011:
On Sun, 2011-03-13 at 19:40 -0400, Tom Lane wrote:
I'm not planning to do anything about this idea right now, since I'm
still hip-deep in collations, but I thought I'd throw
On Mon, Mar 14, 2011 at 10:09 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Joshua D. Drake's message of dom mar 13 23:20:01 -0300 2011:
On Sun, 2011-03-13 at 19:40 -0400, Tom Lane wrote:
I'm not planning to do anything about this idea right now, since I'm
still
Robert Haas wrote:
On Mon, Mar 14, 2011 at 8:42 AM, Bruce Momjian br...@momjian.us wrote:
Simon Riggs wrote:
On Fri, 2011-03-11 at 20:44 -0500, Bruce Momjian wrote:
Looking at the code, it seems we create shared invalidation messages for
temporary table activity? ?Is this true? ?Should
Excerpts from Robert Haas's message of lun mar 14 11:18:24 -0300 2011:
On Mon, Mar 14, 2011 at 10:09 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
It sure would be nice to be able to do it only during the last scan.
Does it really matter? What Tom was describing sounded
On Mon, Mar 14, 2011 at 10:21 AM, Bruce Momjian br...@momjian.us wrote:
Since your original email is fairly unclear about what you think the
problem is, it's a bit hard to speculate here, but like Simon, I don't
see any obvious problem here. Maybe you're asking not so much about
inserts,
On Mon, Mar 14, 2011 at 10:25 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of lun mar 14 11:18:24 -0300 2011:
On Mon, Mar 14, 2011 at 10:09 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
It sure would be nice to be able to do it only during
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of lun mar 14 11:18:24 -0300 2011:
Does it really matter? What Tom was describing sounded embarassingly cheap.
That was my thought exactly. If you could even measure the added cost
of doing that, I'd be
Robert Haas wrote:
On Mon, Mar 14, 2011 at 4:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
On fre, 2011-03-11 at 12:50 -0500, Bruce Momjian wrote:
It has bothered me that many of our time routines use special magic
constants
On Mon, Mar 14, 2011 at 10:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Note that we could remove the correlation
calculations from ANALYZE altogether.
Only if you don't mind having them only get updated when somebody
vacuums. If a table is mostly getting inserted into, it may not get
vacuumed
On 12.03.2011 18:17, Tom Lane wrote:
Does the SQL
standard have anything to say on the matter, or is there a precedent in
the behavior of TSQL or other DBMSes?
Tom,
SQL standard let it open for implementers.
The other DBMS - for which I am/was collation expert - takes afair the
Simon Riggs wrote:
On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
On fre, 2011-03-11 at 12:50 -0500, Bruce Momjian wrote:
It has bothered me that many of our time routines use special magic
constants for time values, e.g. 24, 12, 60, etc.
The attached patch changes
On Mon, 2011-03-14 at 10:42 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
On fre, 2011-03-11 at 12:50 -0500, Bruce Momjian wrote:
It has bothered me that many of our time routines use special magic
constants for time values,
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 14, 2011 at 10:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Note that we could remove the correlation
calculations from ANALYZE altogether.
Only if you don't mind having them only get updated when somebody
vacuums. If a table is mostly
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 14, 2011 at 4:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
I think it's much clearer with the plain numbers.
Yeh. It's not like the values 24, 12 or 60 were going to change.
I
Magnus Hagander mag...@hagander.net writes:
On Mon, Mar 14, 2011 at 14:43, Robert Haas robertmh...@gmail.com wrote:
Also, the text is not accurate: nothing has been automatically changed
to anything. The pg_hba.conf file is just as it was. You could say
something like ident authentication on
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 14, 2011 at 4:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
I think it's much clearer with the plain numbers.
Yeh. It's not like the values 24, 12 or 60
Tom Lane wrote:
Greg Stark gsst...@mit.edu writes:
On Sat, Mar 12, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote:
OK, funny guys. ;-) Can someone give me the right text. Obviously I
don' know what template0 is used for either. Is it pg_dumpall perhaps?
template0:
On Mon, Mar 14, 2011 at 16:17, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Mar 14, 2011 at 14:43, Robert Haas robertmh...@gmail.com wrote:
Also, the text is not accurate: nothing has been automatically changed
to anything. The pg_hba.conf file is
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Yeah, I think that the right way to approach this is to have initdb
comment *both* of those databases. I don't like that specific wording
for template0 though. Maybe
template0: unmodified copy of original template1 database
Hello
I am sending a very simple patch that enhance a autocomplete for
format and linestyle attributes
regards
Pavel Stehule
*** ./src/bin/psql/tab-complete.c.orig 2011-03-14 11:59:22.0 +0100
--- ./src/bin/psql/tab-complete.c 2011-03-14 16:23:41.596278154 +0100
***
***
Hi Selena,
On Mon, 2011-03-07 at 22:44 -0800, Selena Deckelmann wrote:
PostgreSQL is applying for GSoC again this year. We're looking for:
* Mentors
* Project ideas
Would you like to mentor? Please let me know! Our application closes
on Friday, so please contact me *before* Friday.
Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
some of them are pretty darn questionable because the underlying
number *isn't* as well defined as all that.
The macro does allow us to centralize comments on their
imprecision,
e.g.:
/*
* DAYS_PER_MONTH is very imprecise. The
Kevin Grittner kevin.gritt...@wicourts.gov writes:
My first reaction that this change was about a net wash in
readability for me -- in a couple places it might save me a few
moments thinking about what the number was meant to represent,
balanced against following the ctag back to the #define
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Yeah, I think that the right way to approach this is to have initdb
comment *both* of those databases. I don't like that specific wording
for template0 though. Maybe
template0: unmodified copy of original
Peter Eisentraut wrote:
On l?r, 2011-03-12 at 12:01 -0500, Tom Lane wrote:
Shouldn't the postgres database get a comment too, while we're at
it? Perhaps default database to connect to?
That's not actually true, though. Maybe it's the default database used
by administration programs? In
2011/3/14 Devrim GÜNDÜZ dev...@gunduz.org:
Hi Selena,
On Mon, 2011-03-07 at 22:44 -0800, Selena Deckelmann wrote:
PostgreSQL is applying for GSoC again this year. We're looking for:
* Mentors
* Project ideas
Would you like to mentor? Please let me know! Our application closes
on
On Mon, Mar 14, 2011 at 12:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
My first reaction that this change was about a net wash in
readability for me -- in a couple places it might save me a few
moments thinking about what the number was meant to
Robert Haas wrote:
On Mon, Mar 14, 2011 at 12:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
My first reaction that this change was about a net wash in
readability for me -- in a couple places it might save me a few
moments thinking about what
Bruce Momjian wrote:
Yeah, I agree. And I do think that there is also some value of having
constants for SECS_PER_MINUTE and MINUTES_PER_HOUR, because otherwise
it can be unclear what 60 means in a particular context. We're at
the high end of what I consider reasonable in terms of
Bruce Momjian br...@momjian.us wrote:
Let me also add that I realize I am often a royal pain in the
neck.
It really stands out compared to all the timid shrinking violets who
post here. ;-)
Seriously, I've always found that a group works best with a mix of
personalities with their
On Mon, Mar 14, 2011 at 8:52 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Mar 11, 2011 at 8:07 PM, Bruce Momjian br...@momjian.us wrote:
Currently, if you create a temporary table with the ON COMMIT action of
DELETE ROWS, the table will truncated for every commit, whether there is
any
I wrote:
In any case, I am sure that that what this describes is not what our
current code does :-(, and that we can't get anywhere close to this with
the existing infrastructure. So at this point I'm thinking that the
safest approach is to rip out the result-collation caching fields and
2011/3/14 Devrim GÜNDÜZ dev...@gunduz.org:
On Mon, 2011-03-14 at 10:28 +0100, Magnus Hagander wrote:
In looking at the peer patch, I notice that initdb still supports
things like -A ident map=foo, but it *only* supports this for ident,
and nothing else. I'm pretty sure this is a leftover from
For historical reasons, what we now think of as VACUUM is referred to
in some portions of the code as lazy vacuum, to distinguish it from
pre-9.0 VACUUM FULL. As I understand it, VACUUM works like this:
- Scan the relation, accumulating a list of tuples to kill.
- When you get to the end of the
Hi,
first i am not sure how the state of the collation work in current git is
supposed to be with all the discussion going on here... but wanted to get out
that bug report:
create table ad_tab (ad_tab_id varchar(32), name varchar(32));
create function test_trg() RETURNS TRIGGER LANGUAGE
I looked into the performance complaint noted here:
http://archives.postgresql.org/pgsql-performance/2011-03/msg00135.php
in which 8.4 and up produce a worse plan than 8.3.
The reason for the change in behavior is that the newer releases
transform the WHERE EXISTS construct to a semi-join. The
Hello,
there was a discussion about impact of number of keyword for parser
speed. I did some synthetic tests and I didn't see any slowness on
pgbench when I increased a number of keywords.
I added a 30 reserved keywords and 30 unreserved keywords.
On my Intel(R) Core(TM)2 Duo CPU E8400 @
Robert Haas robertmh...@gmail.com writes:
I'm not quite sure how we'd decide whether to do a really lazy
vacuum or the kind we do now. The case where this approach wins big
is when there are few or no dead tuples. In that case, we do a lot of
work looking at the indexes and we don't get much
Stefan Huehner ste...@huehner.org writes:
first i am not sure how the state of the collation work in current git is
supposed to be with all the discussion going on here... but wanted to get out
that bug report:
I think the current state is plpgsql is about completely broken for
collation
On Mon, Mar 14, 2011 at 4:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'm not quite sure how we'd decide whether to do a really lazy
vacuum or the kind we do now. The case where this approach wins big
is when there are few or no dead tuples. In that
Pavel Stehule pavel.steh...@gmail.com writes:
there was a discussion about impact of number of keyword for parser
speed. I did some synthetic tests and I didn't see any slowness on
pgbench when I increased a number of keywords.
I don't see any particular reason to suppose that pgbench would be
On 3/14/11 1:34 PM, Tom Lane wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
there was a discussion about impact of number of keyword for parser
speed. I did some synthetic tests and I didn't see any slowness on
pgbench when I increased a number of keywords.
I don't see any particular
On Mon, Mar 14, 2011 at 8:33 PM, Robert Haas robertmh...@gmail.com wrote:
I'm not sure about that either, although I'm not sure of the reverse
either. But before I invest any time in it, do you have any other
good ideas for addressing the it stinks to scan the entire index
every time we
Hi Daniel,
I have also, coincidentally, encountered corruption of a system
catalog index -- 8.3.11 -- I have saved the file for forensics. Is it
possible that I also receive a copy of this program?
Will it be possible for you to share the file/logs off-list with me? I
can also try to do
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 14, 2011 at 4:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Um, if there are *no* dead tuples then we don't look at the indexes
anyway ...
But you do still have to scan the heap twice.
Seems like that should be fixable ... is the second pass
As Heikki says, maybe this wouldn't be an issue at all if we can do it
during ANALYZE instead, but I don't know if that works.
I'm not convinced you can get a sufficiently good estimate from a small
subset of pages.
Note that if this requires VACUUM rather than ANALYZE, it introduces a
Josh Berkus j...@agliodbs.com writes:
I'm not convinced you can get a sufficiently good estimate from a small
subset of pages.
Note that if this requires VACUUM rather than ANALYZE, it introduces a
problem for data warehousing users, who can go years between vacuums of
their largest tables.
On 3/14/11 5:51 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
I'm not convinced you can get a sufficiently good estimate from a small
subset of pages.
Note that if this requires VACUUM rather than ANALYZE, it introduces a
problem for data warehousing users, who can go years
On Mon, Mar 14, 2011 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
there was a discussion about impact of number of keyword for parser
speed. I did some synthetic tests and I didn't see any slowness on
pgbench when I increased a number of
On Tue, Mar 15, 2011 at 12:27 AM, Josh Berkus j...@agliodbs.com wrote:
Note that if this requires VACUUM rather than ANALYZE, it introduces a
problem for data warehousing users, who can go years between vacuums of
their largest tables.
I don't understand, are they going years between vacuums
I don't understand, are they going years between vacuums because their
data is static? In which case the index correlation won't change. Or
is it append-only, in which case I suspect the newly appended data is
likely to have the same correlation as the old data.
Append-only. And yes, one
I would like to apply the attached patch to git_changelog for use in
creating the major release notes. I specifically added these flags:
--author-after Show author after the commit
--master-only Show commits made exclusively to the master branch
--reverse-order Show commits in
On Mon, Mar 14, 2011 at 7:40 PM, Greg Stark gsst...@mit.edu wrote:
On Mon, Mar 14, 2011 at 8:33 PM, Robert Haas robertmh...@gmail.com wrote:
I'm not sure about that either, although I'm not sure of the reverse
either. But before I invest any time in it, do you have any other
good ideas for
On Mon, Mar 14, 2011 at 8:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 14, 2011 at 4:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Um, if there are *no* dead tuples then we don't look at the indexes
anyway ...
But you do still have to scan the
Hi,
I have installed PostgreSQL 8.4 on Windows 2008 R2 64 bit server. However, the
PostgreSQL service stops intermittently.
Is PostgreSQL 8.4 supported on Windows 2008 R2?
Does PostgreSQL 8.4 have any known issue on Windows 2008 R2?
The following is pg log when the service stopped:
71 matches
Mail list logo
