Hello Robert,
I am not objecting to the functionality; I'm objecting to bolting on
ad-hoc operators one at a time. I think an expression syntax would
let us do this in a much more scalable way. If I had time, I'd go do
that, but I don't. We could add abs(x) and hash(x) and it would all
be gr
Hi Stephen
Can I help with something, it is there some open question?
Regards
Pavel
2014-09-08 6:27 GMT+02:00 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
> > ignore_nulls in array_to_json_pretty probably is not necessary. On second
> > hand, the cost is zero, and we can
>I will repeat the above tests with high load on CPU and using the benchmark
given by Fujii-san and post the results.
Average % of CPU usage at user level for each of the compression algorithm
are as follows.
CompressionMultipleSingle
Off81.1338
>The Russian changes are perhaps not such a big deal because they've
>done that sort of thing before, but this is an earful:
>
> Australian eastern time zone abbreviations are now AEST/AEDT not
> EST, and similarly for the other Australian zones. That is, for
> eastern standard and day
On Thu, Sep 11, 2014 at 9:10 AM, Dilip kumar wrote:
>
>
> I have done the testing and behavior is as per expectation,
>
> Do we need to do some document change? I mean is this limitation on
windows is mentioned anywhere ?
I don't think currently such a limitation is mentioned in docs,
however I t
On 09/10/2014 11:23 PM, Tom Lane wrote:
> In connection with a question asked today on pgsql-general, I had
> occasion to go check the release announcements for the IANA timezone
> database files, and it turns out that there are some big changes in
> 2014f:
> http://mm.icann.org/pipermail/tz-announ
On 20 August 2014 19:49, Amit Kapila Wrote
> There are some comments I would like to share with you
>
>
>
> 1. Rebase the patch to current GIT head.
>Done.
>> + initStringInfo(&symlinkfbuf);
>>
>> I think declaration and initialization of symlinkfbuf string
On Thu, Sep 11, 2014 at 5:21 AM, Heikki Linnakangas
wrote:
> On 08/28/2014 10:10 AM, Michael Paquier wrote:
>>
>> + #synchronous_standby_num = -1 # number of standbys servers using sync
>> rep
>
>
> To be honest, that's a horrible name for the GUC. Back when synchronous
> replication was implement
I use benchmarksql with more than 200 clients on pg 9.3.3. when the test is
going on, I collect all the process stack. I found about 100 processes are
blocked by btree insert. Another 100 are blocked by xloginsert.
Does btree has bad performance in concurrency scenarios?
Sum:66
#0 0x7f8273
On Thu, Jun 12, 2014 at 01:40:59PM +0200, Andres Freund wrote:
> Hi Tom,
>
> On 2014-06-06 15:44:25 -0400, Tom Lane wrote:
> > I figured it'd be easy enough to get a better estimate by adding another
> > counter to count just LIVE and INSERT_IN_PROGRESS tuples (thus effectively
> > assuming that i
On Tue, Jun 10, 2014 at 10:30:24AM -0400, Robert Haas wrote:
> On Tue, Jun 10, 2014 at 10:18 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> I don't agree with this analysis. If the connection is closed after
> >> the client sends a COMMIT and before it gets a response, then the
> >> client mus
On Tue, Jun 17, 2014 at 08:46:00PM -0400, Bruce Momjian wrote:
> On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote:
> > >> Can't you compare it to the historic default value? I mean, add an
> >
On Mon, Jun 9, 2014 at 11:17:41AM +0200, Magnus Hagander wrote:
> On Wednesday, June 4, 2014, Tom Lane wrote:
>
> Magnus Hagander writes:
> > On Tue, Jun 3, 2014 at 6:38 PM, Tom Lane wrote:
> >> Another thought is we could make pg_basebackup simply skip any files
> that
> >
* Vik Fearing (vik.fear...@dalibo.com) wrote:
> On 09/08/2014 06:17 AM, Stephen Frost wrote:
> > * Vik Fearing (vik.fear...@dalibo.com) wrote:
> >> On 09/02/2014 10:17 PM, Marko Tiikkaja wrote:
> >>> Yeah, I think I like this better than allowing all of them without the
> >>> database name.
> >>
>
On 09/08/2014 06:17 AM, Stephen Frost wrote:
> * Vik Fearing (vik.fear...@dalibo.com) wrote:
>> On 09/02/2014 10:17 PM, Marko Tiikkaja wrote:
>>> Yeah, I think I like this better than allowing all of them without the
>>> database name.
>>
>> Why? It's just a noise word!
>
> Eh, because it ends up
On Fri, Sep 5, 2014 at 07:39:36PM -0400, Bruce Momjian wrote:
> On Wed, Sep 3, 2014 at 05:17:17PM -0400, Robert Haas wrote:
> > > I had a look at this and came upon a problem --- there is no multi-xid
> > > SQL data type, and in fact the system catalogs that store mxid values
> > > use xid, e.g.:
On 10.9.2014 21:34, Robert Haas wrote:
> On Wed, Sep 10, 2014 at 3:12 PM, Tomas Vondra wrote:
>> On 10.9.2014 20:25, Heikki Linnakangas wrote:
>>> On 09/10/2014 01:49 AM, Tomas Vondra wrote:
I also did a few 'minor' changes to the dense allocation patch, most
notably:
* renamed
On Wed, Sep 10, 2014 at 4:29 PM, Bruce Momjian wrote:
> On Wed, Sep 10, 2014 at 11:43:52AM -0400, Robert Haas wrote:
>> But there are a couple of obvious problems with this idea, too, such as:
>>
>> 1. It's really complicated and a ton of work.
>> 2. It would break pg_upgrade pretty darn badly unl
On Wed, Sep 10, 2014 at 4:01 PM, Robert Haas wrote:
>> Yes, although my issue with the hooks was not that you only provided them
>> for 2 functions, but the fact that it had no structure and the
>> implementation was "if hook set do this, else do that" which I don't see
>> like a good way of doing
Another commitfest week has passed, and here are still. There are now 24
patches in "Needs Review" state, and 8 in "Ready for Committer". I'm not
paying attention to the "Waiting on Author" patches - once we're close
to zero on the other patches, those will be bounced back.
The good news is th
Robert Haas wrote:
> On Wed, Sep 10, 2014 at 9:47 AM, Alvaro Herrera
> wrote:
> > I attach some additional minor suggestions to your patch.
>
> I don't see any attachment.
Uh. Here it is.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Traini
On Wed, Sep 10, 2014 at 11:43:52AM -0400, Robert Haas wrote:
> But there are a couple of obvious problems with this idea, too, such as:
>
> 1. It's really complicated and a ton of work.
> 2. It would break pg_upgrade pretty darn badly unless we employed some
> even-more-complex strategy to mitigat
On 08/28/2014 10:10 AM, Michael Paquier wrote:
+ #synchronous_standby_num = -1 # number of standbys servers using sync rep
To be honest, that's a horrible name for the GUC. Back when synchronous
replication was implemented, we had looong discussions on this feature.
It was called "quorum comm
On Tue, Sep 9, 2014 at 6:03 PM, Petr Jelinek wrote:
>> - The remaining functions are pq_init(), pq_comm_reset(), pq_flush(),
>> pq_flush_if_writable(), pq_is_send_pending(), pq_putmessage(),
>> pq_putmessage_noblock(), pq_startcopyout(), and pq_endcopyout().
>> These are the ones that I think are
On Wed, Sep 10, 2014 at 9:47 AM, Alvaro Herrera
wrote:
> I attach some additional minor suggestions to your patch.
I don't see any attachment.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
On Wed, Sep 10, 2014 at 3:12 PM, Tomas Vondra wrote:
> On 10.9.2014 20:25, Heikki Linnakangas wrote:
>> On 09/10/2014 01:49 AM, Tomas Vondra wrote:
>>> I also did a few 'minor' changes to the dense allocation patch, most
>>> notably:
>>>
>>> * renamed HashChunk/HashChunkData to MemoryChunk/MemoryC
I had a cursory look at this patch and the discussions around this.
ISTM there are actually two new features in this: 1) allow CHECK
constraints on foreign tables, and 2) support inheritance for foreign
tables. How about splitting it into two?
- Heikki
--
Sent via pgsql-hackers mailing lis
On 10.9.2014 20:25, Heikki Linnakangas wrote:
> On 09/10/2014 01:49 AM, Tomas Vondra wrote:
>> I also did a few 'minor' changes to the dense allocation patch, most
>> notably:
>>
>> * renamed HashChunk/HashChunkData to MemoryChunk/MemoryChunkData
>>The original naming seemed a bit awkward.
>
>
On 10.9.2014 20:55, Heikki Linnakangas wrote:
> On 09/10/2014 09:31 PM, Robert Haas wrote:
* the chunks size is 32kB (instead of 16kB), and we're using 1/4
threshold for 'oversized' items
We need the threshold to be >=8kB, to trigger the special case
within Allo
On Wed, Sep 10, 2014 at 3:02 PM, Tomas Vondra wrote:
> On 10.9.2014 20:31, Robert Haas wrote:
>> On Wed, Sep 10, 2014 at 2:25 PM, Heikki Linnakangas
>> wrote:
>>> The dense-alloc-v5.patch looks good to me. I have committed that with minor
>>> cleanup (more comments below). I have not looked at th
On 10.9.2014 20:31, Robert Haas wrote:
> On Wed, Sep 10, 2014 at 2:25 PM, Heikki Linnakangas
> wrote:
>> The dense-alloc-v5.patch looks good to me. I have committed that with minor
>> cleanup (more comments below). I have not looked at the second patch.
>
> Gah. I was in the middle of doing this
On 10.9.2014 20:25, Heikki Linnakangas wrote:
> On 09/10/2014 01:49 AM, Tomas Vondra wrote:
>> I also did a few 'minor' changes to the dense allocation patch, most
>> notably:
>>
>> * renamed HashChunk/HashChunkData to MemoryChunk/MemoryChunkData
>>The original naming seemed a bit awkward.
>
>
On 09/10/2014 09:31 PM, Robert Haas wrote:
On Wed, Sep 10, 2014 at 2:25 PM, Heikki Linnakangas
wrote:
The dense-alloc-v5.patch looks good to me. I have committed that with minor
cleanup (more comments below). I have not looked at the second patch.
Gah. I was in the middle of doing this. Sig
As discussed on the thread "Spinlocks and compiler/memory barriers",
now that we've made the spinlock primitives function as compiler
barriers (we think), it should be possible to remove volatile
qualifiers from many places in the source code. The attached patch
does this in lwlock.c. If the chan
On 09/10/2014 11:28 AM, Heikki Linnakangas wrote:
On 09/10/2014 05:57 PM, Fabien COELHO wrote:
Hello Heikki,
I looked closer at the this, and per Jan's comments, realized that we don't
log the lag time in the per-transaction log file. I think that's a serious
omission; when --rate is used, th
On Wed, Sep 10, 2014 at 2:25 PM, Heikki Linnakangas
wrote:
> The dense-alloc-v5.patch looks good to me. I have committed that with minor
> cleanup (more comments below). I have not looked at the second patch.
Gah. I was in the middle of doing this. Sigh.
>> * the chunks size is 32kB (instead o
On Wed, Sep 10, 2014 at 1:36 PM, Peter Geoghegan wrote:
>> In order to know how much we're
>> giving up in that case, we need the exact number I asked you to
>> provide in my previous email: the ratio of the cost of strcoll() to
>> the cost of memcmp().
>>
>> I see that you haven't chosen to provi
On 09/10/2014 01:49 AM, Tomas Vondra wrote:
On 9.9.2014 16:09, Robert Haas wrote:
On Mon, Sep 8, 2014 at 5:53 PM, Tomas Vondra wrote:
So I only posted the separate patch for those who want to do a review,
and then a "complete patch" with both parts combined. But it sure may be
a bit confusing.
2014-09-10 0:13 GMT+02:00 Andres Freund :
> On 2014-09-09 22:22:45 +0200, Andres Freund wrote:
> > I plan to push this soon.
>
> Done.
>
> Thanks for the patch!
>
Thank you very much
Pavel
>
> Andres Freund
>
> --
> Andres Freund http://www.2ndQuadrant.com/
> PostgreSQL D
On Tue, Sep 9, 2014 at 2:00 PM, Robert Haas wrote:
> Boiled down, what you're saying is that you might have a set that
> contains lots of duplicates in general, but not very many where the
> abbreviated-keys also match. Sure, that's true.
Abbreviated keys are not used in the case where we do a (
> "Tomas" == Tomas Vondra writes:
Tomas> If we can get rid of the excessive ChainAggregate, that's
Tomas> certainly enough for now.
I found an algorithm that should provably give the minimal number of sorts
(I was afraid that problem would turn out to be NP-hard, but not so - it's
solvable
Wrong thread...
On 09/10/2014 03:04 AM, Kyotaro HORIGUCHI wrote:
Hmm. Sorry, I misunderstood the specification.
You approach that coloring tokens seems right, but you have
broken the parse logic by adding your code.
Other than the mistakes others pointed, I found that
- non-SQL-ident like to
On Tue, Sep 9, 2014 at 10:08 AM, Arthur Silva wrote:
> I'm continuously studying Postgres codebase. Hopefully I'll be able to make
> some contributions in the future.
>
> For now I'm intrigued about the extensive use of memory alignment. I'm sure
> there's some legacy and some architecture that re
On 09/10/2014 04:35 PM, Marko Tiikkaja wrote:
Speaking of good looks, should I add it to the next commitfest as a new
patch, or should we try and get someone to review it like this?
Let's handle this in this commitfest.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On 09/10/2014 05:57 PM, Fabien COELHO wrote:
Hello Heikki,
I looked closer at the this, and per Jan's comments, realized that we don't
log the lag time in the per-transaction log file. I think that's a serious
omission; when --rate is used, the schedule lag time is important information
to mak
On Wed, Sep 10, 2014 at 4:48 AM, Fabien COELHO wrote:
> Note I did not start with the non uniform stuff, but Mitsumasa-san sent a
> gaussian distribution patch and I jumped onto the wagon to complement it
> with an exponential distribution patch. I knew when doing it that is was not
> enough, but
In connection with a question asked today on pgsql-general, I had
occasion to go check the release announcements for the IANA timezone
database files, and it turns out that there are some big changes in
2014f:
http://mm.icann.org/pipermail/tz-announce/2014-August/23.html
The Russian changes ar
On Tue, Sep 9, 2014 at 6:00 PM, Andres Freund wrote:
> On 2014-09-09 17:54:03 -0400, Robert Haas wrote:
>> So, that's committed, then.
>
> Yay, finally.
>
>> I think we should pick something that uses
>> spinlocks and is likely to fail spectacularly if we haven't got this
>> totally right yet, and
Hello Heikki,
I looked closer at the this, and per Jan's comments, realized that we don't
log the lag time in the per-transaction log file. I think that's a serious
omission; when --rate is used, the schedule lag time is important information
to make sense of the result. I think we have to ap
Hi,
I find typo in your patch. Please confirm.
@line 239
- agg->sum2_lag = 0;
+ agg->sum_lag = 0;
And back patch is welcome for me.
Best Regards,
--
Mitsumasa KONDO
On 09/09/2014 03:35 PM, Fabien COELHO wrote:
Hello Heikki,
I think we have to reconsider what we're reporting in 9.4, when --rate
is enabled, even though it's already very late in the release cycle.
It's a bad idea to change the definition of latency between 9.4 and 9.5,
so let's get it right
Thomas Munro wrote:
> @@ -2022,7 +2030,7 @@ EvalPlanQualFetch(EState *estate, Relation relation,
> int lockmode, bool noWait,
>*/
> test = heap_lock_tuple(relation, &tuple,
>
> estate->
Fujii Masao wrote:
> On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
> wrote:
> > PENDING_LIST_CLEANUP_SIZE and work_mem, for this setting.
> > Wouldn't it be easy-to-use to have only one parameter,
> > PENDING_LIST_CLEANUP_SIZE? How about setting PENDING_LIST_CLEANUP_SIZE to
> > work_mem as the
On 9/10/14 1:38 PM, Heikki Linnakangas wrote:
On 09/10/2014 02:26 PM, Marko Tiikkaja wrote:
So I wonder if I shouldn't try and instead keep the
code closer to what it is in HEAD right now; I could call
enlargeStringInfo() first, then hand out a pointer to b64_encode (or
b64_decode()) and finally
On Wed, Sep 3, 2014 at 12:08 AM, Christoph Berg wrote:
> Re: Vik Fearing 2014-09-02 <5405d2d9.9050...@dalibo.com>
>> > Uhm, are we agreed on the decision on not to backpatch this? I would
>> > think this should have been part of the initial ALTER SYSTEM SET patch
>> > and thus should be backpatch
On 09/10/2014 02:26 PM, Marko Tiikkaja wrote:
On 9/9/14 11:01 AM, I wrote:
On 9/9/14 10:54 AM, Heikki Linnakangas wrote:
So I think this (and the corresponding dearmor code too) should be
refactored to use a StringInfo that gets enlarged as needed, instead of
hoping to guess the size correctly
On 9/9/14 11:01 AM, I wrote:
On 9/9/14 10:54 AM, Heikki Linnakangas wrote:
So I think this (and the corresponding dearmor code too) should be
refactored to use a StringInfo that gets enlarged as needed, instead of
hoping to guess the size correctly beforehand. To ease review, might
make sense to
On Wed, Sep 10, 2014 at 1:45 AM, Petr Jelinek wrote:
> Hi,
>
> I recently wanted several times to have slave server prepared at certain
> point in time to reduce the time it takes for it to replay remaining WALs
> (say I have pg_basebackup -x on busy db for example).
In your example, you're think
Thanks for reviewing the patch!
On Wed, Sep 10, 2014 at 4:57 PM, Heikki Linnakangas
wrote:
> On 08/28/2014 11:38 AM, Fujii Masao wrote:
>>
>> On Thu, Jun 19, 2014 at 5:29 PM, Ian Barwick wrote:
>>>
>>> - minor rewording for the description, mentioning that statements will
>>>still be logged
On 9/10/14 12:05 PM, Etsuro Fujita wrote:
(2014/09/10 18:33), Marko Tiikkaja wrote:
You can already change *this patch* to do ModifyTable <- Limit <-
LockRows. If we think that's what we want, we should rewrite this patch
right now.
I think it might be relatively easy to do that for single-ta
(2014/09/10 18:33), Marko Tiikkaja wrote:
On 9/10/14 11:25 AM, Etsuro Fujita wrote:
The reason is because I think that after implementing #2, we should
re-implement this feature by extending the planner to produce a plan
tree such as ModifyTable+Limit+Append, maybe with LockRows below the
Limit
On Wed, Sep 10, 2014 at 5:35 PM, Etsuro Fujita
wrote:
> (2014/09/10 12:31), Fujii Masao wrote:
>>
>> On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
>> wrote:
>>>
>>> (2014/09/09 22:17), Fujii Masao wrote:
Attached is the updated version of the patch.
>
>
>>> I took a quick review on th
On 9/10/14 11:25 AM, Etsuro Fujita wrote:
The reason is because I think that after implementing #2, we should
re-implement this feature by extending the planner to produce a plan
tree such as ModifyTable+Limit+Append, maybe with LockRows below the
Limit node. Such an approach would prevent dupli
On Sep10, 2014, at 10:54 , Kyotaro HORIGUCHI
wrote:
> Under the new specifications, next_token will work as following,
>
> - USER : token: USER , case-insensitive
> - "USeR": token: USeR , case-SENSITIVE
> - "+uSeR" : token: +uSeR , case-SENSITIVE
> - "+UsE"R : token: +UsEr ,
Hmm...
case-insensitive mathing could get multiple matches, which should be an
error but I've forgot to do so.
regards,
2014/09/10 17:54 "Kyotaro HORIGUCHI" :
> And one known defect is that you will get a bit odd message if
> you put an hba line having keywords quoted or prefixed with '+',
> fo
(2014/09/10 16:57), Marko Tiikkaja wrote:
On 2014-09-10 04:25, Etsuro Fujita wrote:
(2014/09/09 18:57), Heikki Linnakangas wrote:
What's not clear to me is whether it make sense to do 1) without 2) ? Is
UPDATE .. LIMIT without support for an ORDER BY useful enough? And if we
apply this patch no
Hello, I had a closer look on this patch.
Finally I think that we need case-insensitive version of
get_role_id and() get_database_id() to acoomplish this patch'es
objective. (This runs full-scans on pg_database or pg_authid X()
And I'd like to propose to change token categorization from
notation-
Hello Robert,
Sure, and I would have looked at that patch and complained that you
were implementing a modulo operator with different semantics than C.
And then we'd be right back where we are now.
[...]
Probably.
To be clear about my intent, which is a summary of what you already know:
I wo
(2014/09/10 12:31), Fujii Masao wrote:
On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
wrote:
(2014/09/09 22:17), Fujii Masao wrote:
Attached is the updated version of the patch.
I took a quick review on the patch. It looks good to me,
but one thing I'm
concerned about is
You wrote:
T
On 10/09/14 18:54, Amit Kapila wrote:
On Wed, Sep 10, 2014 at 5:46 AM, Mark Kirkwood
mailto:mark.kirkw...@catalyst.net.nz>>
wrote:
>
> In terms of the effect of the patch - looks pretty similar to the
scale 2000 results for read-write, but read-only is a different and more
interesting story - u
On 08/28/2014 11:38 AM, Fujii Masao wrote:
On Thu, Jun 19, 2014 at 5:29 PM, Ian Barwick wrote:
- minor rewording for the description, mentioning that statements will
still be logged as DEBUG1 even if parameter set to 'off' (might
prevent reports of the kind "I set it to 'off', why am I st
On 2014-09-10 04:25, Etsuro Fujita wrote:
(2014/09/09 18:57), Heikki Linnakangas wrote:
What's not clear to me is whether it make sense to do 1) without 2) ? Is
UPDATE .. LIMIT without support for an ORDER BY useful enough? And if we
apply this patch now, how much of it needs to be rewritten aft
On 10 September 2014 00:21, Tom Lane wrote:
> Thom Brown writes:
> > I find this in pgbench.c:
>
> > #ifdef FD_SETSIZE
> > #define MAXCLIENTS (FD_SETSIZE - 10)
> > #else
> > #define MAXCLIENTS 1024
> > #endif
>
> FD_SETSIZE is supposed to be defined, according to the POSIX spec:
>
>
73 matches
Mail list logo
