On Thu, Mar 6, 2014 at 10:33 PM, Bruce Momjian br...@momjian.us wrote:
On Thu, Mar 6, 2014 at 09:50:56PM +0400, Oleg Bartunov wrote:
Hi there,
Looks like consensus is done. I and Teodor are not happy with it, but
what we can do :) One thing I want to do is to reserve our
contribution to
On Thu, Mar 6, 2014 at 11:28 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
So here my opinion on what we should do:
1. Forget about hstore2
2. Add GIN and GIST operator classes to jsonb, if they're ready for commit
pretty darn soon. If not, punt them to next release.
For #2, would we
On Wed, Mar 5, 2014 at 8:39 AM, Bruce Momjian br...@momjian.us wrote:
So, I am going to ask a back-track question and ask why we can't move
hstore into core.
This is exactly the opposite of what should be happening. Now, jsonb
might make it into core because of the json precedent but the
On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 03/05/2014 09:39 AM, Bruce Momjian wrote:
So, I am going to ask a back-track question and ask why we can't move
hstore into core. Is this a problem with the oids of the hstore data
On Wed, Mar 5, 2014 at 9:52 AM, Bruce Momjian br...@momjian.us wrote:
On Wed, Mar 5, 2014 at 09:19:33AM -0600, Merlin Moncure wrote:
On Wed, Mar 5, 2014 at 8:39 AM, Bruce Momjian br...@momjian.us wrote:
So, I am going to ask a back-track question and ask why we can't move
hstore into core
On Wed, Mar 5, 2014 at 10:19 AM, Andres Freund and...@2ndquadrant.com wrote:
There's the absolutely significant issue that you cannot reasonably
write extensions that interact on a C level. You can't call from
extension to extension directly, but you can from extension to pg core
provided
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
*All* non-sql standard types ought to be in extensions in an ideal world.
While there's certainly much to be said for the idea that jsonb should be
an extension, I don't think we have
On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost sfr...@snowman.net wrote:
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
*All* non-sql standard types ought to be in extensions
On Wed, Mar 5, 2014 at 11:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
While there's certainly much to be said for the idea that jsonb should be
an extension, I don't think we have
On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost sfr...@snowman.net wrote:
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost sfr...@snowman.net wrote:
Yeah, from what I gather you're suggesting, that's more-or-less move it
all to core, except that all
On Wed, Mar 5, 2014 at 2:45 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Merlin Moncure escribió:
It doesn't magically fix it, but at least provides a way forward. If
the function you want to modify is in an extension 'foo', you get to
put your new stuff in 'foo2' extension. That way
On Wed, Mar 5, 2014 at 4:24 PM, Stephen Frost sfr...@snowman.net wrote:
* Merlin Moncure (mmonc...@gmail.com) wrote:
On Wed, Mar 5, 2014 at 2:46 PM, Stephen Frost sfr...@snowman.net wrote:
I don't see why we can't do exactly what you're suggesting in core.
Because you can't (if you're
On Tue, Mar 4, 2014 at 6:48 AM, Teodor Sigaev teo...@sigaev.ru wrote:
On Tue, Mar 4, 2014 at 2:44 AM, Teodor Sigaev teo...@sigaev.ru wrote:
Do we have function to trim right zeros in numeric?
Fixed, pushed to github
(https://github.com/feodor/postgres/tree/jsonb_and_hstore). Now it used
On Fri, Feb 28, 2014 at 2:01 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-28 14:45:29 -0500, Andrew Dunstan wrote:
Well, the jsonb portion of this is arguably the most ready, certainly it's
had a lot more on-list review.
Having crossread both patches I tend to agree with this. I
On Fri, Feb 28, 2014 at 8:57 AM, Stephen Frost sfr...@snowman.net wrote:
The specific issues mentioned on this thread look more like bugs to be
addressed or additional operators which need to be implemented for
jsonb (imv, that should really be done for 9.4, but we have this
deadline
On Fri, Feb 28, 2014 at 1:45 PM, Andrew Dunstan and...@dunslane.net wrote:
Well, the jsonb portion of this is arguably the most ready, certainly it's
had a lot more on-list review.
That is definitely true. Also, the jsonb type does not introduce any
new patterns that are not already covered
On Thu, Feb 27, 2014 at 1:11 PM, Josh Berkus j...@agliodbs.com wrote:
However, we had this discussion already in November-December, which
resulted in the current patch. Now you and Robert want to change the
rules on Andrew, which means Andrew is ready to quit, and we go another
year without
On Tue, Feb 25, 2014 at 10:07 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/26/2014 06:21 AM, Merlin Moncure wrote:
On Tue, Feb 25, 2014 at 4:03 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/25/2014 12:12 PM, Robert Haas wrote:
I don't agree that jsonb should be preferred in all
On Tue, Feb 25, 2014 at 3:57 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
On 02/25/2014 08:54 PM, Josh Berkus wrote:
That's called a straw man argument, Robert.
Me: We should recommend that people use jsonb unless they have a
specific reason for using json.
We could also make the opposite
On Wed, Feb 26, 2014 at 11:41 AM, Josh Berkus j...@agliodbs.com wrote:
On 02/26/2014 07:02 AM, Merlin Moncure wrote:
On Tue, Feb 25, 2014 at 3:57 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
It is not in any specs, but nevertheless all major imlementations do it and
some code depends
On Wed, Feb 26, 2014 at 12:05 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/26/2014 09:57 AM, Merlin Moncure wrote:
What is not going to be so clear for users (particularly without good
supporting documentation) is how things break down in terms of usage
between hstore and jsonb
On Mon, Feb 24, 2014 at 1:15 PM, Andrew Dunstan and...@dunslane.net wrote:
On 02/24/2014 11:06 AM, Merlin Moncure wrote:
On Mon, Feb 24, 2014 at 9:08 AM, Merlin Moncure mmonc...@gmail.com
wrote:
On Mon, Feb 24, 2014 at 8:46 AM, Merlin Moncure mmonc...@gmail.com
wrote:
I still find
On Tue, Feb 25, 2014 at 4:03 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/25/2014 12:12 PM, Robert Haas wrote:
I don't agree that jsonb should be preferred in all but a handful of
situations. Nor do I agree that partisanship belongs in our
documentation. Therefore, -1 for your proposal to
On Mon, Feb 24, 2014 at 12:20 AM, Josh Berkus j...@agliodbs.com wrote:
All,
Here's a draft cleanup on the JSON section of the Datatype docs. Since
there's been a bunch of incremental patches on this, I just did a diff
against HEAD.
I looked over json-functions a bit, but am not clear on
On Mon, Feb 24, 2014 at 8:46 AM, Merlin Moncure mmonc...@gmail.com wrote:
I still find the phrasing as jsonb is more efficient for most
purposes to be a bit off Basically, the text json type is faster for
serialization/deserialization pattern (not just document preservation)
and jsonb
On Mon, Feb 24, 2014 at 9:08 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Mon, Feb 24, 2014 at 8:46 AM, Merlin Moncure mmonc...@gmail.com wrote:
I still find the phrasing as jsonb is more efficient for most
purposes to be a bit off Basically, the text json type is faster for
serialization
On Tue, Feb 11, 2014 at 3:35 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
On 02/11/2014 01:16 AM, Merlin Moncure wrote:
On Mon, Feb 10, 2014 at 5:52 PM, Andres Freund and...@2ndquadrant.com
wrote:
It works in enough cases atm that it's worthwile trying to keep it
working. Sure, it could
On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
On 02/10/2014 05:05 AM, Andres Freund wrote:
I'd suggest making the format discernible from possible different future
formats, to allow introducing a proper binary
On Mon, Feb 10, 2014 at 12:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
Teodor privately suggested something similar. I
On Mon, Feb 10, 2014 at 5:02 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-10 11:59:53 -0600, Merlin Moncure wrote:
On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
On 02/10/2014 05:05 AM, Andres
On Mon, Feb 10, 2014 at 5:38 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-10 17:35:12 -0600, Merlin Moncure wrote:
Wrong. You still need to have code that checks the server version and
see if it's supported (particularly for sending) and as there is *no
protocol negotiation
On Mon, Feb 10, 2014 at 5:52 PM, Andres Freund and...@2ndquadrant.com wrote:
It works in enough cases atm that it's worthwile trying to keep it
working. Sure, it could be better, but it's what we have right now. Atm
it's e.g. the only realistic way to copy larger amounts of bytea between
On Mon, Feb 10, 2014 at 6:24 PM, Andres Freund and...@2ndquadrant.com wrote:
And if we add a new format version in 9.5 we need to make it discernible
from the 9.4 format. Without space for a format indicator we'd have to
resort to ugly tricks like defining the high bit in the first byte set
On Mon, Feb 10, 2014 at 6:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Feb 10, 2014 at 6:24 PM, Andres Freund and...@2ndquadrant.com
wrote:
And if we add a new format version in 9.5 we need to make it discernible
from the 9.4 format. Without
On Monday, February 10, 2014, Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-10 19:01:48 -0600, Merlin Moncure wrote:
On Mon, Feb 10, 2014 at 6:39 PM, Tom Lane t...@sss.pgh.pa.usjavascript:;
wrote:
Merlin Moncure mmonc...@gmail.com javascript:; writes:
On Mon, Feb 10, 2014 at 6
On Wed, Feb 5, 2014 at 12:44 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
send/recv functions are also needed for binary-format COPY. IMHO jsonb must
have send/recv functions. All other built-in types have them, except for
types like 'smgr', 'aclitem' and 'any*' that no-one should be
On Wed, Feb 5, 2014 at 10:22 AM, Andrew Dunstan and...@dunslane.net wrote:
I'm actually surprised we have an alternate binary wire format for
jsonb at all; json is explicitly text and I'm not sure what the use
case of sending the internal structure is. Meaning, maybe jsonb
send/recv should be
On Wed, Feb 5, 2014 at 11:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If we had infinite time/manpower, this wouldn't really be an issue.
We don't, though, and so I suggest that this may be one of the better
things to toss overboard.
The hstore send/recv functions have basically the same
On Wed, Feb 5, 2014 at 1:03 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/05/2014 07:48 AM, Merlin Moncure wrote:
Another point I'm struggling with is
what jsonb brings to the table that isn't covered either hstore or
json; working through a couple of cases I find myself not using the
jsonb
On Wed, Feb 5, 2014 at 2:37 PM, Andrew Dunstan and...@dunslane.net wrote:
The time for this discussion was months ago. I would not have spent many
many hours of my time if I thought it was going to be thrown away. I find
this attitude puzzling, to say the least. You were a major part of the
On Wed, Feb 5, 2014 at 3:03 PM, Josh Berkus j...@agliodbs.com wrote:
That was the original goal. However, Oleg and Teodor's late delivery of
Hstore2 limited what Andrew could do for JSONB before CF4 started.
yeah. anyways, I'm good on this point.
merlin
--
Sent via pgsql-hackers mailing
On Sat, Feb 1, 2014 at 4:20 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-01-30 14:07:42 -0500, Andrew Dunstan wrote:
+ para id=functions-json-table
+ xref linkend=functions-json-creation-table shows the functions that
are
+ available for creating typejson/type values.
+
On Fri, Jan 31, 2014 at 4:03 AM, Oleg Bartunov obartu...@gmail.com wrote:
Hmm,
neither me, nor Teodor have experience and knowledge with
populate_record() and moreover hstore here is virgin and we don't know
the right behaviour, so I think we better take it from jsonb, once
Andrew realize it.
On Fri, Jan 31, 2014 at 8:45 AM, Andrew Dunstan and...@dunslane.net wrote:
On 01/31/2014 08:57 AM, Merlin Moncure wrote:
On Fri, Jan 31, 2014 at 4:03 AM, Oleg Bartunov obartu...@gmail.com
wrote:
Hmm,
neither me, nor Teodor have experience and knowledge with
populate_record() and moreover
On Fri, Jan 31, 2014 at 9:26 AM, Andrew Dunstan and...@dunslane.net wrote:
On 01/31/2014 09:53 AM, Merlin Moncure wrote:
On Fri, Jan 31, 2014 at 8:45 AM, Andrew Dunstan and...@dunslane.net
wrote:
On 01/31/2014 08:57 AM, Merlin Moncure wrote:
On Fri, Jan 31, 2014 at 4:03 AM, Oleg Bartunov
On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan and...@dunslane.net wrote:
Now, if we're agreed on that, I then also wonder if the 'as_text'
argument needs to exist at all for the populate functions except for
backwards compatibility on the json side (not jsonb). For non-complex
structures it
On Thu, Jan 30, 2014 at 1:07 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/29/2014 04:56 PM, Andrew Dunstan wrote:
On 01/29/2014 01:03 PM, Andrew Dunstan wrote:
On 01/27/2014 10:43 PM, Andrew Dunstan wrote:
On 01/26/2014 05:42 PM, Andrew Dunstan wrote:
Here is the latest set of
On Thu, Jan 30, 2014 at 4:52 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/30/2014 07:21 PM, Merlin Moncure wrote:
postgres=# select hstore(row(1, array[row(1, array[row(1,
array[1,2])::z])::y])::x);
hstore
On Tue, Jan 28, 2014 at 5:58 AM, Christian Kruse
christ...@2ndquadrant.com wrote:
Hi,
On 28/01/14 13:51, Heikki Linnakangas wrote:
Oh darn, I remembered we had already committed this, but clearly not. I'd
love to still get this into 9.4. The latest patch (hugepages-v5.patch) was
pretty much
On Wed, Jan 29, 2014 at 9:08 AM, Andrew Dunstan and...@dunslane.net wrote:
In the jsonb patch I have been working on, I have replicated all of what I
call the json processing functions, and I will shortly add analogs for the
new functions in that category json_to_record and json_to_recordset.
On Wed, Jan 29, 2014 at 12:03 PM, Andrew Dunstan and...@dunslane.net wrote:
Only change in functionality is the addition of casts between jsonb and
json.
The other changes are the merge with the new json functions code, and
rearrangement of the docs changes to make them less ugly. Essentially
On Wed, Jan 29, 2014 at 3:56 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/29/2014 01:03 PM, Andrew Dunstan wrote:
On 01/27/2014 10:43 PM, Andrew Dunstan wrote:
On 01/26/2014 05:42 PM, Andrew Dunstan wrote:
Here is the latest set of patches for nested hstore and jsonb.
Because
On Mon, Jan 27, 2014 at 9:43 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/26/2014 05:42 PM, Andrew Dunstan wrote:
Here is the latest set of patches for nested hstore and jsonb.
Because it's so large I've broken this into two patches and compressed
them. The jsonb patch should work
Looks like this review is against jsonb-5, not jsonb-6.
oh yep -- shoot, sorry for the noise.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jan 28, 2014 at 10:46 AM, Andrew Dunstan and...@dunslane.net wrote:
On 01/28/2014 11:29 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The problem is not the indexterm element, it's the space that might
exist outside it. Are we using block level elements like para
On Tue, Jan 28, 2014 at 12:09 PM, Josh Berkus j...@agliodbs.com wrote:
On 01/28/2014 09:58 AM, Merlin Moncure wrote:
yeah. note: I think the json documentation needs *major* overhaul. too
much is going in inside the function listings where there really
should be a big breakout discussing
On Fri, Jan 24, 2014 at 3:26 PM, Josh Berkus j...@agliodbs.com wrote:
On 01/24/2014 12:59 PM, Andrew Dunstan wrote:
On 01/24/2014 03:40 PM, Laurence Rowe wrote:
For consistency with the existing json functions (json_each,
json_each_text, etc.) it might be better to add separate
On Sun, Jan 12, 2014 at 4:38 AM, Craig Ringer cr...@2ndquadrant.com wrote:
Implicit casts to text, anybody?
This backward compatibility break orphaned the company I work for on
8.1 until last year and very nearly caused postgres to be summarily
extirpated (only rescued at the last minute by my
On Mon, Jan 13, 2014 at 3:45 PM, David Fetter da...@fetter.org wrote:
On Mon, Jan 13, 2014 at 10:40:57AM -0600, Merlin Moncure wrote:
This project has no deprecation policy,
I believe it actually does, although it's not a formal, written
policy. Would you like to help draft one up?
Lack
On Fri, Jan 10, 2014 at 2:04 AM, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 10 January 2014 00:36, Marko Tiikkaja ma...@joh.to wrote:
On 1/10/14, 1:20 AM, Merlin Moncure wrote:
I'm piling on: it's not clear at all to me why you've special cased
this to lower_bound=1. First of all
On Fri, Jan 10, 2014 at 3:52 AM, Marko Tiikkaja ma...@joh.to wrote:
On 1/10/14, 10:41 AM, Merlin Moncure wrote:
What's needed for better iteration support (IMO)
is a function that does what unnest does but returns an array on
indexes (one per dimsension) -- a generalization
On Fri, Jan 10, 2014 at 6:00 AM, Florian Pflug f...@phlo.org wrote:
On Jan10, 2014, at 11:00 , Merlin Moncure mmonc...@gmail.com wrote:
On Fri, Jan 10, 2014 at 3:52 AM, Marko Tiikkaja ma...@joh.to wrote:
On 1/10/14, 10:41 AM, Merlin Moncure wrote:
What's needed for better iteration support
On Fri, Jan 10, 2014 at 4:10 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Fri, Jan 10, 2014 at 1:26 PM, Jim Nasby j...@nasby.net wrote:
On 1/9/14, 10:58 PM, Tom Lane wrote:
Jim Nasby j...@nasby.net writes:
ISTM that allowing users to pick arbitrary lower array bounds was a huge
mistake.
On Thu, Jan 9, 2014 at 11:08 AM, Marko Tiikkaja ma...@joh.to wrote:
On 1/9/14 5:44 PM, Florian Pflug wrote:
On Jan9, 2014, at 14:57 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 19 December 2013 08:05, Pavel Stehule pavel.steh...@gmail.com wrote:
length should be irrelevant to fact so
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 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
On Tue, Dec 31, 2013 at 3:51 PM, Mark Dilger markdil...@yahoo.com wrote:
The BDR documentation
http://wiki.postgresql.org/images/7/75/BDR_Presentation_PGCon2012.pdf
says,
Physical replication forces us to use just one
node: multi-master required for write scalability
Physical
On Sat, Dec 14, 2013 at 6:20 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-12-13 15:49:45 -0600, Merlin Moncure wrote:
On Fri, Dec 13, 2013 at 12:32 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 13, 2013 at 11:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
And while we're
On Fri, Dec 13, 2013 at 12:32 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 13, 2013 at 11:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
And while we're on the subject ... isn't bgworker_die() utterly and
completely broken? That unconditional elog(FATAL) means that no process
using
On Thu, Dec 12, 2013 at 4:02 AM, knizhnik knizh...@garret.ru wrote:
On 12/12/2013 11:42 AM, Pavel Stehule wrote:
it is interesting idea. For me, a significant information from comparation,
so we do some significantly wrong. Memory engine should be faster naturally,
but I don't tkink it can be
On Thu, Dec 12, 2013 at 12:18 PM, knizhnik knizh...@garret.ru wrote:
IMHO it is strange to see such small default values in postgresql
configuration.
This (low default work mem) is because of three things:
1) Most queries do not really need a lot of work mem
2) Work mem stacks with each query
On Mon, Dec 9, 2013 at 1:40 PM, knizhnik knizh...@garret.ru wrote:
Hello!
I want to annouce my implementation of In-Memory Columnar Store extension
for PostgreSQL:
Documentation: http://www.garret.ru/imcs/user_guide.html
Sources: http://www.garret.ru/imcs-1.01.tar.gz
Any
On Wed, Dec 11, 2013 at 10:08 AM, knizhnik knizh...@garret.ru wrote:
1. Calls in PL/pgSQL are very slow - about 1-2 micsroseconds at my computer.
Just defining insertion per-row trigger with empty procedure increase time
of insertion of 6 million records twice - from 7 till 15 seconds. If
On Tue, Dec 10, 2013 at 1:18 AM, Thomas Munro mu...@ip9.org wrote:
Hi
I have been wondering what the minimum useful heap table compression
system would be for Postgres, in order to reduce disk footprint of
large mostly static datasets. Do you think an approach similar to the
static
On Mon, Dec 9, 2013 at 10:53 AM, Euler Taveira eu...@timbira.com.br wrote:
On 09-12-2013 13:12, Merlin Moncure wrote:
This is pretty neat. Couple minor questions:
*) Aren't you *en*coding data into json, not the other way around (decoding?)
Yes. The 'decoding' came from the functionality
On Mon, Dec 9, 2013 at 7:03 AM, Euler Taveira eu...@timbira.com.br wrote:
Hi,
A few months ago, it was proposed [1] that would be interested to have a
json output plugin for logical decoding. Here it is.
Each transaction is a JSON object that can contain xid (optional),
timestamp
On Mon, Dec 2, 2013 at 10:26 PM, David Fetter da...@fetter.org wrote:
On Tue, Dec 03, 2013 at 11:15:36AM +0800, Craig Ringer wrote:
On 11/28/2013 03:24 AM, David Fetter wrote:
WITH, or SRF, or whatever, the point is that we need to be able to
specify what we're sending--probably single
On Wed, Dec 4, 2013 at 1:39 PM, David Fetter da...@fetter.org wrote:
On Wed, Dec 04, 2013 at 12:43:44PM -0600, Merlin Moncure wrote:
On Mon, Dec 2, 2013 at 10:26 PM, David Fetter da...@fetter.org wrote:
On Tue, Dec 03, 2013 at 11:15:36AM +0800, Craig Ringer wrote:
On 11/28/2013 03:24 AM
On Wed, Dec 4, 2013 at 2:31 PM, Jonathan Corbet cor...@lwn.net wrote:
For those interested in the details... (1) It's not quite 50/50, that's one
bound for how the balance is allowed to go. (2) Anybody trying to add
tunables to the kernel tends to run into resistance. Exposing thousands of
On Wed, Nov 27, 2013 at 4:20 AM, Shigeru Hanada
shigeru.han...@gmail.com wrote:
Hi Merlin,
2013/11/22 Merlin Moncure mmonc...@gmail.com:
On Thu, Nov 21, 2013 at 6:43 PM, Shigeru Hanada
shigeru.han...@gmail.com wrote:
2013/11/22 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com
On Tue, Nov 26, 2013 at 9:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja ma...@joh.to writes:
On 11/26/13 2:24 PM, Pavel Stehule wrote:
yes, but we can define new statement like \sq+ (Show Query)
There's already \p; might not be too difficult to add a \p+ which would
also show the
On Mon, Nov 25, 2013 at 3:33 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
there is other issue - simply parser will be really user unfriendly, and
user friendly parser will not by simply :(
If simple things are hard to implement, get
On Mon, Nov 25, 2013 at 3:07 PM, Andreas Karlsson andr...@proxel.se wrote:
Hi,
When looking at table 8-1 at
http://www.postgresql.org/docs/9.3/static/datatype.html i noticed that all
types except for json was in alphabetical order. I have attached a patch
which fixes this.
By the way
On Thu, Nov 21, 2013 at 6:43 PM, Shigeru Hanada
shigeru.han...@gmail.com wrote:
2013/11/22 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Nov 21, 2013 at 9:05 AM, Bruce Momjian br...@momjian.us wrote:
I know join pushdowns seem insignificant, but it helps
On Fri, Nov 22, 2013 at 2:23 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
2013/11/21 Merlin Moncure mmonc...@gmail.com
On Thu, Nov 21, 2013 at 1:09 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
I wrote new styles for psql table borders.
http://postgres.cz/wiki
On Fri, Nov 22, 2013 at 8:45 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Pavel Stehule escribió:
2013/11/21 Peter Eisentraut pete...@gmx.net
Maybe make the border setting a string containing the various characters
by index. Then everyone can create their own crazy borders.
I
On Fri, Nov 22, 2013 at 4:34 PM, Mike Blackwell mike.blackw...@rrd.com wrote:
I believe the section you are reading refers to the BEGIN keyword in the
procedural language plpgsql, not the SQL 'BEGIN' command. The issue stems
from confusing two distinct languages both of which, along with
On Thu, Nov 21, 2013 at 9:02 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-11-21 16:25:02 +0200, Heikki Linnakangas wrote:
Hmm. All callers of RecoveryInProgress() must be prepared to handle the case
that RecoveryInProgress() returns true, but the system is no longer in
recovery. No
On Thu, Nov 21, 2013 at 9:09 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-11-21 09:08:05 -0600, Merlin Moncure wrote:
This code is in a very hot code path. Are we *sure* that the read
barrier is fast enough that we don't want to provide an alternate
function that only returns
On Thu, Nov 21, 2013 at 10:37 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 21.11.2013 17:08, Merlin Moncure wrote:
On Thu, Nov 21, 2013 at 9:02 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-11-21 16:25:02 +0200, Heikki Linnakangas wrote:
Hmm. All callers
On Thu, Nov 21, 2013 at 9:05 AM, Bruce Momjian br...@momjian.us wrote:
Where are we on the remaining possible pushdowns for foreign data
wrappers, particularly the Postgres one? I know we do WHERE restriction
pushdowns in 9.3, but what about join and aggregate pushdowns? Is
anyone working on
On Thu, Nov 21, 2013 at 1:09 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
I wrote new styles for psql table borders.
http://postgres.cz/wiki/Pretty_borders_in_psql
This patch is simply and I am think so some styles can be interesting for
final presentation.
great. hm, maybe we
On Tue, Nov 19, 2013 at 11:59 AM, Josh Berkus j...@agliodbs.com wrote:
On 11/19/2013 08:14 AM, Robert Haas wrote:
On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
I am sure you could also devise an json encoding scheme
where white space is significant ;)
I don't
On Sun, Nov 17, 2013 at 10:19 PM, Andrew Dunstan and...@dunslane.net wrote:
I don't think any name that doesn't begin with json is acceptable. I could
live with jsonb. It has the merit of brevity, but maybe it's a tad too
close to json to be the right answer.
I think that seems right. Couple
On Mon, Nov 18, 2013 at 12:10 PM, Josh Berkus j...@agliodbs.com wrote:
Merlin,
*) Aside from the text in and out routines, how is 'jsbonb' different
from the coming 'nested hstore'? Enough to justify two code bases?
In/out functions and defaults are all different. Otherwise, the two
On Thu, Nov 14, 2013 at 1:54 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
On 11/14/2013 08:17 PM, Merlin Moncure wrote:
On Thu, Nov 14, 2013 at 11:34 AM, David E. Wheeler
da...@justatheory.com wrote:
On Nov 14, 2013, at 7:07 AM, Merlin Moncure mmonc...@gmail.com wrote:
This is exactly what
On Fri, Nov 15, 2013 at 6:06 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
But: I very, very much agree with the other concerns around this. This
should be a patch to fix single user mode, not one to make postgres into
a single process database. It's not, and trying to make it by using
On Fri, Nov 15, 2013 at 1:51 PM, David E. Wheeler da...@justatheory.com wrote:
On Nov 15, 2013, at 6:35 AM, Merlin Moncure mmonc...@gmail.com wrote:
Here are the options on the table:
1) convert existing json type to binary flavor (notwithstanding objections)
2) maintain side by side types
On Fri, Nov 15, 2013 at 2:37 PM, Andrew Dunstan and...@dunslane.net wrote:
On 11/15/2013 03:25 PM, Merlin Moncure wrote:
On Fri, Nov 15, 2013 at 1:51 PM, David E. Wheeler da...@justatheory.com
wrote:
On Nov 15, 2013, at 6:35 AM, Merlin Moncure mmonc...@gmail.com wrote:
Here
On Fri, Nov 15, 2013 at 2:54 PM, Josh Berkus j...@agliodbs.com wrote:
On 11/15/2013 12:25 PM, Merlin Moncure wrote:
Kinda yes, kinda no. Here's a rough sketch of what I'm thinking:
*) 'json' type internally has a binary as well a text representation.
The text representation is basically
401 - 500 of 1941 matches
Mail list logo
