On 3 May 2013 21:53, Jeff Davis wrote:
> At this point, I don't think more changes are required.
After detailed further analysis, I agree, no further changes are required.
I think the code in that area needs considerable refactoring to
improve things. I've looked for an easy way to avoid callin
2013/4/24 Bruce Momjian :
> Thanks for the many suggestions on improving the 9.3 release notes.
> There were many ideas I would have never thought of. Please keep the
> suggestions coming.
One small suggestion:
Have session id (%c) in log_line_prefix
always output
Hi!
On Wed, Apr 24, 2013 at 6:41 AM, Bruce Momjian wrote:
> Thanks for the many suggestions on improving the 9.3 release notes.
> There were many ideas I would have never thought of. Please keep the
> suggestions coming.
Some observations:
1. "Allow CREATE TABLE IF NOT EXISTS to succeed for a
On Sat, May 4, 2013 at 08:34:18PM +0900, Ian Lawrence Barwick wrote:
> 2013/4/24 Bruce Momjian :
> > Thanks for the many suggestions on improving the 9.3 release notes.
> > There were many ideas I would have never thought of. Please keep the
> > suggestions coming.
>
> One small suggestion:
>
>
On Sat, May 4, 2013 at 03:50:34PM +0300, Marti Raudsepp wrote:
> Hi!
>
> On Wed, Apr 24, 2013 at 6:41 AM, Bruce Momjian wrote:
> > Thanks for the many suggestions on improving the 9.3 release notes.
> > There were many ideas I would have never thought of. Please keep the
> > suggestions coming.
On Sat, May 4, 2013 at 03:50:34PM +0300, Marti Raudsepp wrote:
> 2. "Dramatically reduce System V shared memory usage"
>
> I find this description misleading. When reading for the first time,
> it sounds as if Postgres memory usage is reduced, but it's actually
> just using different kind of shar
2013/5/4 Bruce Momjian :
> On Sat, May 4, 2013 at 08:34:18PM +0900, Ian Lawrence Barwick wrote:
>> 2013/4/24 Bruce Momjian :
>> > Thanks for the many suggestions on improving the 9.3 release notes.
>> > There were many ideas I would have never thought of. Please keep the
>> > suggestions coming.
On Sat, May 4, 2013 at 11:55:09PM +0900, Ian Lawrence Barwick wrote:
> >> more pedantically
> >> accurate:
> >>
> >>
> >>
> >> Have session id (%c) in >> linkend="guc-log-line-prefix">log_line_prefix
> >> always pad the PID value with zeros so at least four
Plural to singular:
s/Allow a streaming replication standbys to/Allow a streaming replication
standby to/
Perhaps this one too? (not sure, 'tooling' just seems strange to my non-native
reading))
s/Allow tooling like pg_receivexlog to run/Allow tools like pg_receivexlog to
run/
thanks,
Consider the following scenario:
create table t1 as select 1 as x;
create materialized view mv1 as select * from t1;
create materialized view mv2 as select * from mv1;
create materialized view mv3 as select * from mv2;
refresh materialized view mv1 with no data;
This state is not dumpable by pg_d
On Sat, May 4, 2013 at 05:12:31PM +0200, Erik Rijkers wrote:
> Plural to singular:
>
> s/Allow a streaming replication standbys to/Allow a streaming replication
> standby to/
>
>
> Perhaps this one too? (not sure, 'tooling' just seems strange to my
> non-native reading))
>
> s/Allow tool
On Fri, May 3, 2013 at 10:19:42PM -0400, Bruce Momjian wrote:
> On Sat, May 4, 2013 at 03:04:33AM +0100, Greg Stark wrote:
> > On Fri, May 3, 2013 at 5:49 PM, Bruce Momjian wrote:
> > > Yes, I think the big question is how much information do we want per
> > > relation that we don't need in the
2013/5/5 Bruce Momjian :
(...)
>> > This is such a minor change I am trying to keep it short.
>>
>> Just out of curiosity, what was the reason for the change in the first place?
>> (Not that it's something I'm particularly passionate about, I just noticed it
>> when listing changes with potential b
On Sun, May 5, 2013 at 01:21:12AM +0900, Ian Lawrence Barwick wrote:
> > Well, basically, if you used %c in log_line_prefix, the session id was
> > not a fixed length, so your output shifted around based on the pid, see:
> >
> >
> > http://www.postgresql.org/message-id/20121012185127.gb31
On Sat, May 4, 2013 at 01:17:44PM -0400, Bruce Momjian wrote:
> Yes, I see it is wrong now. I came up with this new query:
>
> SELECT to_hex(EXTRACT(EPOCH FROM backend_start)::integer) || '.' ||
> regexp_replace('' || to_hex(pid), '^0*(.*)$', '\1')
> FROM pg_stat_
Bruce Momjian writes:
> OK, how are we for bata packaging on Monday? I don't see how we can do
> that until we decide on how to handle unlogged materialized views.
In the interests of moving the discussion along, attached are draft
patches to show what I think we should do in 9.3. The first pat
On 24.4.2013 05:41, Bruce Momjian wrote:
> Thanks for the many suggestions on improving the 9.3 release notes.
> There were many ideas I would have never thought of. Please keep the
> suggestions coming.
Lovely, good job Bruce!
I've checked descriptions of changes I've been working on, and I thi
On Thu, May 2, 2013 at 4:19 PM, Heikki Linnakangas
wrote:
>* Learning cube extension to store dimensions with different data
> types. Such index would be good alternative to compound key B-Tree
> multi-index (suitable for diapason queries and data ordering).
>
> You mean, a cube containing som
On 24.4.2013 05:41, Bruce Momjian wrote:
> Thanks for the many suggestions on improving the 9.3 release notes.
> There were many ideas I would have never thought of. Please keep the
> suggestions coming.
Lovely, good job Bruce!
I've checked descriptions of changes I've been working on, and I thi
On Sat, May 4, 2013 at 07:59:40PM +0200, Tomas Vondra wrote:
> On 24.4.2013 05:41, Bruce Momjian wrote:
> > Thanks for the many suggestions on improving the 9.3 release notes.
> > There were many ideas I would have never thought of. Please keep the
> > suggestions coming.
>
> Lovely, good job Br
Hackers,
we have SP-GiST opclass called suffix tree. Apparently is NOT suffix tree.
In suffix tree we insert every suffix of source string into the tree.
http://en.wikipedia.org/wiki/Suffix_tree
Actually opclass implemented radix tree or patricia tree.
http://en.wikipedia.org/wiki/Radix_tree
Likel
Hello.
>* Learning cube extension to store dimensions with different data types.
> Such index would be good alternative to compound key B-Tree multi-index
> (suitable for diapason queries and data ordering).
>
> You mean, a cube containing something else than floats? I don't think we want
... btw, I noticed a minor misfeature in the current implementation:
regression=# select pg_relation_size('int8_tbl');
pg_relation_size
--
8192
(1 row)
regression=# create materialized view mv1 as select * from int8_tbl;
SELECT 5
regression=# select pg_relation_size
Robert Haas writes:
> On Wed, Apr 17, 2013 at 2:06 PM, Tom Lane wrote:
>> I think this breaks contrib/adminpack, and perhaps other extensions.
>> They'd not be hard to fix with script changes, but they'd be broken.
>>
>> In general, we would now have a situation where relocatable extensions
>> c
Michael Paquier writes:
> On Thu, May 2, 2013 at 11:01 PM, Tom Lane wrote:
>> Perhaps it'd be a good idea to emit the command tag on receiving a
>> non-tuple-bearing result, just to make this more obvious.
> Yes, the command tag would be a good idea, combined with the watch time
> that other com
Tom Lane writes:
>>> In general, we would now have a situation where relocatable extensions
>>> could never be installed into pg_catalog. That might be OK, but at
>>> least it would need to be documented.
I've been idly trying to think of examples where that would be a
problem, without success.
Tom Lane wrote:
> Kevin Grittner writes:
>> What do you see that I'm missing?
>
> TBH, if I had 20-20 foresight, we'd not be having this
> discussion: either I could see that you're right and this patch
> isn't going to cause us enormous pain, or I could put my finger
> on exactly where and why
On Fri, May 3, 2013 at 7:54 PM, Andrew Dunstan wrote:
> I'd be happy to use 75 or whatever if we could convince the email tools not
> to truncate the subject lines at 50.
Usually even truncated lines are still useful. Just try to avoid lines like
This commit adds new code to implement a new fe
On 05/05/13 10:41, Kevin Grittner wrote:
[...]
removing unlogged matviews for 9.3
[...]
So you are going to unlog the unlogged matviews from 9.3? :-)
More seriously, I think this will result in a better solution for 9.4 -
as it seems to me to be too rushed to fix it now
Cheers,
Gavin.
On Sat, May 04, 2013 at 01:17:44PM -0400, Bruce Momjian wrote:
> On Sun, May 5, 2013 at 01:21:12AM +0900, Ian Lawrence Barwick wrote:
> > > Well, basically, if you used %c in log_line_prefix, the session id was
> > > not a fixed length, so your output shifted around based on the pid, see:
> > >
>
On Sat, May 4, 2013 at 10:01:18PM -0400, Noah Misch wrote:
> On Sat, May 04, 2013 at 01:17:44PM -0400, Bruce Momjian wrote:
> > On Sun, May 5, 2013 at 01:21:12AM +0900, Ian Lawrence Barwick wrote:
> > > > Well, basically, if you used %c in log_line_prefix, the session id was
> > > > not a fixed l
Bruce Momjian writes:
> OK, so we can either use 4 hex digits minimum and have a fixed with on
> most platforms, extend it to 8 hex digits, or revert the entire
> fixed-width idea.
I think we should lose the idea that it's fixed-width. 16-bit PIDs are
a limitation whose days are obviously number
32 matches
Mail list logo
