On Sun, Dec 22, 2013 at 09:43:57PM -0500, Robert Haas wrote:
On Fri, Dec 20, 2013 at 12:01 PM, Oskari Saarenmaa o...@ohmu.fi wrote:
This allows the variables to be moved from .data to .rodata section which
means that more data can be shared by processes and makes sure that nothing
can
On 01/02/2014 07:52 PM, Claudio Freire wrote:
No, because this doesn't scale automatically with the bandwidth-delay
product. It also requires that the client buffers queries and their
parameters even though the network has to do that anyway.
Why not? I'm talking about transport-level
On Fri, Jan 3, 2014 at 10:22 AM, Florian Weimer fwei...@redhat.com wrote:
On 01/02/2014 07:52 PM, Claudio Freire wrote:
No, because this doesn't scale automatically with the bandwidth-delay
product. It also requires that the client buffers queries and their
parameters even though the network
Robert Haas escribió:
The other thing that bothers me here is that, while a normalized
command string sounds great in theory, as soon as you want to allow
(for example) mapping schema A on node 1 to schema B on node 2, the
wheels come off: you'll have to deparse that normalized command string
Robert Haas escribió:
On Mon, Dec 30, 2013 at 10:59 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
One problem I see is length of time before freezing multis: they live
for far too long, causing the SLRU files to eat way too much disk space.
I ran burnmulti in a loop, creating multis
Hi,
On 2014-01-03 11:11:13 -0300, Alvaro Herrera wrote:
Yeah. Since we expect mxids to be composed at a much lower rate than
xids, we can keep pg_multixact small without needing to increase the
rate of full table scans.
I don't think that's necessarily true - there have been several
On 2013-12-12 10:01:21 -0500, Robert Haas wrote:
On Thu, Dec 12, 2013 at 7:04 AM, Andres Freund and...@2ndquadrant.com wrote:
I think there'll always be a bit of a difference between slots for
physical and logical data, even if 90% of the implementation is the
same. We can signal that
Claudio Freire klaussfre...@gmail.com writes:
On Fri, Jan 3, 2014 at 10:22 AM, Florian Weimer fwei...@redhat.com wrote:
Loading data into the database isn't such an uncommon task. Not everything
is OLTP.
Truly, but a sustained insert stream of 10 Mbps is certainly way
beyond common non-OLTP
On 12/24/13, 10:29 AM, Fabien COELHO wrote:
On 12/22/13, 2:36 AM, Fabien COELHO wrote:
I'm not sure whether the policy is to update the version number of the
extension for such a change. As the library is always isn.so, two
versions cannot live in parallel anyway. If it is useful, the second
This patch doesn't apply anymore.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/03/2014 04:20 PM, Tom Lane wrote:
I think Florian has a good point there, and the reason is this: what
you are talking about will be of exactly zero use to applications that
want to see the results of one query before launching the next. Which
eliminates a whole lot of apps. I suspect
On 12/17/13, 8:16 PM, Maciek Sakrejda wrote:
(now with patch--sorry about that)
This patch doesn't apply.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/25/13, 6:40 AM, MauMau wrote:
pg_regress must wait for postgres to terminate by calling waitpid(),
because it invoked postgres directly. The attached
pg_regress_pg_stop.patch does this. If you like the combination of this
and the original fix for pg_ctl in one patch, please use
Michael Paquier escribió:
Hi all,
Please find attached updated patches for the support of REINDEX
CONCURRENTLY, renamed 2.0 for the occasion:
- 20131114_1_index_drop_comments.patch, patch that updates some
comments in index_drop. This updates only a couple of comments in
index_drop but has
On Fri, Jan 3, 2014 at 9:46 AM, Florian Weimer fwei...@redhat.com wrote:
On 01/03/2014 04:20 PM, Tom Lane wrote:
I think Florian has a good point there, and the reason is this: what
you are talking about will be of exactly zero use to applications that
want to see the results of one query
On Fri, Jan 3, 2014 at 12:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Claudio Freire klaussfre...@gmail.com writes:
On Fri, Jan 3, 2014 at 10:22 AM, Florian Weimer fwei...@redhat.com wrote:
Loading data into the database isn't such an uncommon task. Not everything
is OLTP.
Truly, but a
On Fri, Jan 3, 2014 at 11:06 AM, Claudio Freire klaussfre...@gmail.com wrote:
On Fri, Jan 3, 2014 at 12:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Claudio Freire klaussfre...@gmail.com writes:
On Fri, Jan 3, 2014 at 10:22 AM, Florian Weimer fwei...@redhat.com wrote:
Loading data into the
If so, there is only the one-liner patch to consider.
This patch doesn't apply anymore. Please submit an updated patch for
the commit fest.
In src/include/utils/elog.h there is an include for utils/errcodes.h
which is generated somehow when compiling postgresql but not present by
On Thu, Jan 2, 2014 at 11:59 AM, Christophe Pettus x...@thebuild.com wrote:
In both cases, the indicated relation was a primary key index. In one case,
rebuilding the primary key index caused the problem to go away permanently
(to date). In the second case, the problem returned even after a
We had the same issues running 9.2.4:
[2013-10-15 00:23:01 GMT/0/15396] WARNING: page 8789807 of relation
base/16429/2349631976 is uninitialized
[2013-10-15 00:23:01 GMT/0/15396] CONTEXT: xlog redo vacuum: rel
1663/16429/2349631976; blk 8858544, lastBlockVacuumed 0
[2013-10-15 00:23:01
I'm trying to figure out why hash joins seem to be systematically underused
in my hands. In the case I am immediately looking at it prefers a merge
join with both inputs getting seq scanned and sorted, despite the hash join
being actually 2 to 3 times faster, where inputs and intermediate working
Jeff Janes jeff.ja...@gmail.com writes:
I'm trying to figure out why hash joins seem to be systematically underused
in my hands. In the case I am immediately looking at it prefers a merge
join with both inputs getting seq scanned and sorted, despite the hash join
being actually 2 to 3 times
On Fri, Jan 3, 2014 at 7:39 AM, Peter Eisentraut pete...@gmx.net wrote:
This patch doesn't apply anymore.
Yes, there was some bit-rot. I previous deferred dealing with a
shift/reduce conflict implied by commit
1b4f7f93b4693858cb983af3cd557f6097dab67b. I've fixed that problem now
using non
On Thu, Jan 02, 2014 at 08:48:24PM +0400, knizhnik wrote:
I want to announce implementation of In-Memory Columnar Store
extension for PostgreSQL.
Vertical representation of data is stored in PostgreSQL shared memory.
Thanks for the hard work!
I noticed a couple of things about this that
Hello,
please find attached the patch that adds basic support for the
pg_stat_archiver system view, which allows users that have continuous
archiving procedures in place to keep track of some important metrics
and information.
Currently, pg_stat_archiver displays:
* archived_wals: number of
Here is a patch for the new json functions I mentioned a couple of
months ago. These are:
json_to_record
json_to_recordset
json_object
json_build_array
json_build_object
json_object_agg
So far there are no docs, but the way these work is illustrated in the
regression
On Fri, Dec 13, 2013 at 4:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, so far as the syntax goes, I'm quite distressed by having to make
REJECTS into a fully-reserved word. It's not reserved according to the
standard, and it seems pretty likely to be something that apps might be
using as a
1. compiling with msvc shows warning in relcache.c
1e:\workspace\postgresql\master\postgresql\src\backend\utils\cache\relcache.c(3959):
warning C4715: 'RelationGetIndexAttrBitmap' : not all control paths
return a value
Attached patch remove_msvc_warning.patch to remove above warning
2. It seems
Hi David,
Sorry, but I do not completely understand your suggestions:
1. IMCS really contains single patch file sysv_shmem.patch.
Applying this patch is not mandatory for using IMCS: it just solves the
problem with support of 256Gb of shared memory.
Right now PostgreSQL is not able to use
29 matches
Mail list logo
