On Sun, Nov 3, 2013 at 3:01 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Sat, Nov 2, 2013 at 10:28 PM, Andrew Dunstan wrote:
>>> What exactly would be the point? Indexes are automatically maintained by
>>> postgres. Something that isn't doesn't seem to me to qualify for the
>>> descriptio
Hi all,
Following the discussions done these last days about wal_level like this one:
http://www.postgresql.org/message-id/cabuevewigm-ppobkgdkm6lzyo+ovrdz7soxn_5by8e8pcae...@mail.gmail.com
Please find attached a patch doing what is written in the $subject.
Thoughts?
--
Michael
commit 5a06f45ca8
On 29.10.2013 03:16, Andres Freund wrote:
Hi,
I've started a valgrind run earlier when trying to run the regression
tests with valgrind --error-exitcode=122 (to cause the regression tests
to fail visibly) but it crashed frequently...
One of them was:
==2184== Invalid write of size 8
==2184==
Amit Kapila writes:
> On Fri, Nov 1, 2013 at 9:50 AM, Tom Lane wrote:
>> I think this is adding fragility for absolutely no meaningful savings.
>> The existing code does not depend on the assumption that the array
>> is filled consecutively and no entries are closed early.
>As I could see, i
On Fri, Nov 1, 2013 at 9:50 AM, Tom Lane wrote:
> Amit Kapila writes:
>> On Thu, Oct 31, 2013 at 2:41 AM, Gurjeet Singh wrote:
>>> Just a small patch; hopefully useful.
>
>> This is valid saving as we are filling array ListenSocket[] in
>> StreamServerPort() serially, so during ClosePostmasterPo
Greetings,
I was poking around the Append node and considering my earlier
suggestion to build an Async method of pulling data out of nodes under
Append which support that option. It looks workable, but I was also
considering simply changing postgres_fdw to use async queries instead-
whi
On Sun, Nov 3, 2013 at 3:58 PM, Florian Weimer wrote:
> I would like to add truly asynchronous query processing to libpq, enabling
> command pipelining. The idea is to to allow applications to auto-tune to
> the bandwidth-delay product and reduce the number of context switches when
> running agai
I would like to add truly asynchronous query processing to libpq,
enabling command pipelining. The idea is to to allow applications to
auto-tune to the bandwidth-delay product and reduce the number of
context switches when running against a local server.
Here's a sketch of what the interface
David Rowley wrote
> I'm sure in the real world there are many cases where a better choice in
> column ordering would save space and save processing times, but is this
> something that we want to leave up to our users?
Right now there is little visibility, from probably 99% of people, that this
is
On Sat, Nov 02, 2013 at 02:25:17PM -0400, Peter Eisentraut wrote:
> This could be removed, but is it something that is actually part of what
> is being tested?
Thanks for spotting Peter. Yes, this should have been used. I just committed a
fix.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot
David Rowley escribió:
> I've just been looking at how alignment of columns in tuples can make the
> tuple larger than needed.
This has been discussed at length previously, and there was a design
proposed to solve this problem. See these past discussions:
http://archives.postgresql.org/pgsql-hac
On Sun, Nov 03, 2013 at 09:40:18PM +1300, Gavin Flower wrote:
> I think the system should PHYSICALLY store the columns in the most
> space efficient order, and have a facility for mapping to & from the
> LOGICAL order - so that users & application developers only have
> worry about the logical orde
On 03/11/13 20:37, David Rowley wrote:
I've just been looking at how alignment of columns in tuples can make
the tuple larger than needed.
I created 2 tables... None of which are very real world, but I was
hunting for the extremes here...
The first table contained an int primary key and then
I've just been looking at how alignment of columns in tuples can make the
tuple larger than needed.
I created 2 tables... None of which are very real world, but I was hunting
for the extremes here...
The first table contained an int primary key and then a total of 10 int
columns and 10 boolean co
14 matches
Mail list logo
