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 mor
1. compiling with msvc shows warning in relcache.c
1>e:\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
On Fri, Dec 13, 2013 at 4:06 PM, Tom Lane 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 table or column
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
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
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 pro
On Fri, Jan 3, 2014 at 7:39 AM, Peter Eisentraut 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 operator precedence,
Jeff Janes 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 faster, where inpu
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
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 GMT/0/153
On Thu, Jan 2, 2014 at 11:59 AM, Christophe Pettus 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 full dump /
>
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
defau
On Fri, Jan 3, 2014 at 11:06 AM, Claudio Freire wrote:
> On Fri, Jan 3, 2014 at 12:20 PM, Tom Lane wrote:
>> Claudio Freire writes:
>>> On Fri, Jan 3, 2014 at 10:22 AM, Florian Weimer wrote:
Loading data into the database isn't such an uncommon task. Not everything
is OLTP.
>>
>>> Tr
On Fri, Jan 3, 2014 at 12:20 PM, Tom Lane wrote:
> Claudio Freire writes:
>> On Fri, Jan 3, 2014 at 10:22 AM, Florian Weimer 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
>
On Fri, Jan 3, 2014 at 9:46 AM, Florian Weimer 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 before launchi
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 b
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
> pg
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 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 th
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 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 usefu
Claudio Freire writes:
> On Fri, Jan 3, 2014 at 10:22 AM, Florian Weimer 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 loads. This is far more specific
On 2013-12-12 10:01:21 -0500, Robert Haas wrote:
> On Thu, Dec 12, 2013 at 7:04 AM, Andres Freund 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 difference by specify
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
Robert Haas escribió:
> On Mon, Dec 30, 2013 at 10:59 PM, Alvaro Herrera
> 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 of 3 members each,
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 str
On Fri, Jan 3, 2014 at 10:22 AM, Florian Weimer 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 has to
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 packets,
On Sun, Dec 22, 2013 at 09:43:57PM -0500, Robert Haas wrote:
> On Fri, Dec 20, 2013 at 12:01 PM, Oskari Saarenmaa 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 accidentall
29 matches
Mail list logo
