On Tue, Sep 9, 2014 at 12:16 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 5, 2014 at 9:19 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Fri, Sep 5, 2014 at 5:17 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
Apart from above, I think for this patch, cat version bump is
On Wed, Sep 10, 2014 at 5:46 AM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz wrote:
On 05/09/14 23:50, Amit Kapila wrote:
On Fri, Sep 5, 2014 at 8:42 AM, Mark Kirkwood
FWIW below are some test results on the 60 core beast with this patch
applied to 9.4. I'll need to do more runs to iron
On 10 September 2014 00:21, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com 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
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
On 08/28/2014 11:38 AM, Fujii Masao wrote:
On Thu, Jun 19, 2014 at 5:29 PM, Ian Barwick i...@2ndquadrant.com 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
On 10/09/14 18:54, Amit Kapila wrote:
On Wed, Sep 10, 2014 at 5:46 AM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz 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
(2014/09/10 12:31), Fujii Masao wrote:
On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp 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
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
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
(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
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 horiguchi.kyot...@lab.ntt.co.jp:
And one known defect is that you will get a bit odd message if
you put an hba line having keywords
On Sep10, 2014, at 10:54 , Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp
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
- +UsER
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
On Wed, Sep 10, 2014 at 5:35 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
(2014/09/10 12:31), Fujii Masao wrote:
On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
(2014/09/09 22:17), Fujii Masao wrote:
Attached is the updated version of the patch.
(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 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
Thanks for reviewing the patch!
On Wed, Sep 10, 2014 at 4:57 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 08/28/2014 11:38 AM, Fujii Masao wrote:
On Thu, Jun 19, 2014 at 5:29 PM, Ian Barwick i...@2ndquadrant.com wrote:
- minor rewording for the description, mentioning that
On Wed, Sep 10, 2014 at 1:45 AM, Petr Jelinek p...@2ndquadrant.com 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
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
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 Wed, Sep 3, 2014 at 12:08 AM, Christoph Berg c...@df7cb.de 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
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
Fujii Masao wrote:
On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp 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
Thomas Munro wrote:
@@ -2022,7 +2030,7 @@ EvalPlanQualFetch(EState *estate, Relation relation,
int lockmode, bool noWait,
*/
test = heap_lock_tuple(relation, tuple,
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
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
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
On Tue, Sep 9, 2014 at 6:00 PM, Andres Freund and...@2ndquadrant.com 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
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
On Wed, Sep 10, 2014 at 4:48 AM, Fabien COELHO coe...@cri.ensmp.fr 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
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
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
On Tue, Sep 9, 2014 at 10:08 AM, Arthur Silva arthur...@gmail.com 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
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
Tomas == Tomas Vondra t...@fuzzy.cz 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
On Tue, Sep 9, 2014 at 2:00 PM, Robert Haas robertmh...@gmail.com 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
2014-09-10 0:13 GMT+02:00 Andres Freund and...@2ndquadrant.com:
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/
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 t...@fuzzy.cz 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
On Wed, Sep 10, 2014 at 1:36 PM, Peter Geoghegan p...@heroku.com 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
On Wed, Sep 10, 2014 at 2:25 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
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,
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
On 09/10/2014 09:31 PM, Robert Haas wrote:
On Wed, Sep 10, 2014 at 2:25 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
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.
That's too
On 10.9.2014 20:31, Robert Haas wrote:
On Wed, Sep 10, 2014 at 2:25 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On Wed, Sep 10, 2014 at 3:02 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 10.9.2014 20:31, Robert Haas wrote:
On Wed, Sep 10, 2014 at 2:25 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
The dense-alloc-v5.patch looks good to me. I have committed that with minor
cleanup (more comments
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 AllocSet. The 1/4 rule is
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.
That's too
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
On Wed, Sep 10, 2014 at 3:12 PM, Tomas Vondra t...@fuzzy.cz 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
On Wed, Sep 10, 2014 at 9:47 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On Tue, Sep 9, 2014 at 6:03 PM, Petr Jelinek p...@2ndquadrant.com 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
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
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 mitigate
Robert Haas wrote:
On Wed, Sep 10, 2014 at 9:47 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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,
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 that
On Wed, Sep 10, 2014 at 4:01 PM, Robert Haas robertmh...@gmail.com 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
On Wed, Sep 10, 2014 at 4:29 PM, Bruce Momjian br...@momjian.us 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
On 10.9.2014 21:34, Robert Haas wrote:
On Wed, Sep 10, 2014 at 3:12 PM, Tomas Vondra t...@fuzzy.cz 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 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 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 reindexing
* 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.
Why? It's just
On Mon, Jun 9, 2014 at 11:17:41AM +0200, Magnus Hagander wrote:
On Wednesday, June 4, 2014, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Jun 3, 2014 at 6:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another thought is we could make
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 br...@momjian.us 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
On Tue, Jun 10, 2014 at 10:30:24AM -0400, Robert Haas wrote:
On Tue, Jun 10, 2014 at 10:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I don't agree with this analysis. If the connection is closed after
the client sends a COMMIT and before it gets a
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 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
On Thu, Sep 11, 2014 at 5:21 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
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 can
be
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:
On Thu, Sep 11, 2014 at 9:10 AM, Dilip kumar dilip.ku...@huawei.com 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
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 daylight
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
73 matches
Mail list logo
