require some fiddling, but it might be a good idea nonetheless?
What fiddling are you thinking of?
> I think we should also consider some more reliable measures to have
> BufferDescriptors cacheline sized, rather than relying on the happy
> accident. Debugging alignment issues isn
it mostly was diagnosed by remote hand debugging, limiting
> insights considerably.
Of course.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
d can be much less than the time reported by psql's \timing
> option, usually because of planning time.
I think that has a lot more to do with network roundtrip time and
protocol/serialization overhead.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
7;t mentioned anything about
buffer pins/refcount side effects in comments above
_bt_finish_split(), even though I believe you should.
A minor stylistic concern is that I think it would be better to only
have one pair of _bt_finish_split()/_bt_getbuf() calls regardless of
the initial value of &#x
On Sun, Feb 2, 2014 at 6:00 AM, Andres Freund wrote:
> On 2014-02-01 19:47:29 -0800, Peter Geoghegan wrote:
>> Here are the results of a benchmark on Nathan Boley's 64-core, 4
>> socket server:
>> http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/amd-4-
ed.
It certainly seems as if the interesting cases are where clients > cores.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
an ran this test with max_connections=201, presumably
to exercise the alignment problem.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
bugging the issue.
I guess that given that *both* cases tested had the patch applied,
that makes sense. However, I would have liked to see a real master
baseline.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
nction between
logical and physical cores matters here.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
especially since
these are only 60 second runs where you're unlikely to accumulate
enough transaction latency information to notice any effect.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
this patch as it relates to his effort to compress FPIs?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
mmenting on this thread, I don't know very much about
compression.
--
Peter Geoghegan
--
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, Feb 4, 2014 at 4:21 AM, Andres Freund wrote:
> Which imo means fixing this got more important...
I strongly agree.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pg
nts for the
quite noticeable effect reported: http://danluu.com/3c-conflict
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
just the
> changes to _bt_moveright, if you want to review just the changes since the
> previous patch I posted.
Cool. I'll take a good look at it tomorrow morning PST.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
current code.
That's true, but I believe that a hardware optimization called
Adjacent Cache Line Prefetch is widely supported by recent
microarchitectures, and is sometimes enabled by default. I'm not
suggesting that that would necessarily radically alter the outcome,
but it is a consi
On Tue, Feb 4, 2014 at 4:24 PM, Peter Geoghegan wrote:
> There is something you have not drawn explicit attention to that is
> very interesting. If we take REL9_3_STABLE tip to be representative
> (built with full -O2 optimization, no assertions just debugging
> symbols), setting max
rst update after a
> checkpoint, and the diff between old and new tuple is not used in that case.
Uh, I really just meant that one thing that might overlap is
considerations around the choice of compression algorithm. I think
that there was some useful discussion of that on the other thread as
On Thu, Jan 23, 2014 at 1:36 PM, Peter Geoghegan wrote:
> So while post-recovery callbacks no longer exist for any
> rmgr-managed-resource, 100% of remaining startup and cleanup callbacks
> concern the simple management of memory of AM-specific recovery
> contexts (for GiST, GiN and
t, caused by commit ac8bc3. I rebased myself, but
that was non-trivial, surprisingly; I had to tweak by hand.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
aboring the point:
* Some callers to _bt_split() and _bt_insertonpg() pass a 'cbuf' that
is not invalid.
* If either of those 2 functions don't unlock + release those buffers,
no one ever will.
* Therefore, at the very least we should unlock + release those
buffers **just because
you can take a look at this again, when you get a chance.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
mail.com
I was under the impression that you agreed that this was independently
valuable, regardless of the outcome here.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Jan 19, 2014 at 2:17 AM, Peter Geoghegan wrote:
> I'm just throwing an error when locking the tuple returns
> HeapTupleInvisible, and the xmin of the tuple is our xid.
I would like some feedback on this point. We need to consider how
exactly to avoid updating the same tuple
at only has to occur when a page split occurs,
as we insert a downlink into the parent page. The big picture here is
that we can exploit the properties of inner pages to do the smallest
amount of work for the largest amount of benefit.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (
se
>> is dangerous.
>
> And I still disagree with this- even in those cases. Those same untuned
> servers are running dirt-simple queries 90% of the time and they won't
> use any more memory from this, while the 10% of the queries which are
> more complicated will greatly i
On Wed, Feb 12, 2014 at 3:55 AM, MauMau wrote:
> FYI, the following stack traces are the ones obtained during two instances
> of hang.
You mentioned a hang during a B-Tree insert operation - do you happen
to have a backtrace that relates to that?
--
Peter Geoghegan
--
Sent via
st_decoding as it currently
stands can be redirected to a third-party wrapper. As you say, it's
pretty cool stuff, so it seems likely that someone will build one for
us.
--
Peter Geoghegan
--
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, Feb 18, 2014 at 11:39 AM, Alvaro Herrera
wrote:
> Is there are reason this wasn't back-patched to 9.3? I think it should
> be.
+1.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
lease (promoted in the
*.2 release notes). On this database, as of right now:
txid_current
──
6242282
(1 row)
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t then re-indexing didn't help, while
VACUUM FREEZE had the immediate effect of making both plans give a
consistent answer.
--
Peter Geoghegan
--
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, Feb 18, 2014 at 5:56 PM, Peter Geoghegan wrote:
> That was my first suspicion, but then re-indexing didn't help, while
> VACUUM FREEZE had the immediate effect of making both plans give a
> consistent answer.
I should add that this is an unremarkable int4 primary key (whi
On Tue, Feb 18, 2014 at 5:50 PM, Alvaro Herrera
wrote:
> Peter Geoghegan wrote:
>> I've had multiple complaints of apparent data loss on 9.3.2 customer
>> databases. There are 2 total, both complaints from the past week, one
>> of which I was able to confirm. The cu
tempt to
repair the damage by hand). I'm reasonably confident that I could get
back an affected database by performing a point-in-time recovery. That
would also give me the benefit of an environment that I could break as
needed.
--
Peter Geoghegan
--
Sent via pgsql-hackers mai
ers couldn't run pg_controldata
even if they'd heard of it...
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
how best to enable jsonb to take
advantage of the new functions and operators?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
You have documentation changes here, but that doesn't really
tell us why this is important.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
r some data journaling FS, I suppose.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,
> because otherwise it will hide/fixup many errors.
Sure, but you might want to account for torn pages anyway.
Particularly if you're interested in some degree of automation, as we
all seem to be.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
E CAST (hstore AS jsonb)
+ WITHOUT FUNCTION AS IMPLICIT;
+
+ CREATE CAST (jsonb AS hstore)
+ WITHOUT FUNCTION AS IMPLICIT;
Is this okay?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
code reads "res == NULL", unlike
above). It appears to have been that way in Git since last year. So,
maybe Andres meant that it *should* look like this?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
varying the behavior of IO routines with a
GUC, since it only varies whitespace, but it is surely pretty
questionable to have this GUC's setting vary the output of hstore_out,
an IMMUTABLE function.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
submitted patch. What's going on?
I'm working off the Github branch here, as of an hour ago, since I was
under the impression that the patches submitted are merely snapshots
of that (plus I happen to strongly prefer not dealing with patch files
for something this big). Which submitted patc
d question. I think having everything in contrib would
make it easier to resolve the disconnect between jsonb and hstore. As
things stand, there is a parallel set of functions and operators for
hstore and jsonb, with the former set much larger than the latter. I'm
not terribly happy with tha
, I believe it matters not a whit to adoption
whether or not it's an extension, except insofar as having it be an
extension helps the implementation effort (that is, that it helps
there be something to adopt), or hinders that effort.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing
arder time
seeing a cost.
To be clear: I would really like for jsonb to have parity with hstore.
I don't understand how you can argue for it being unfortunate that the
original json may occupy a privileged position as a core type over
jsonb on the one hand, while not also taking issue with js
sically the same
thing. It might be that certain facets of the nested hstore
implementation reflect a need to accommodate jsonb, but there are no
ones that I'm currently aware of that I find at all objectionable.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-ha
t
LOCATION: hstore_yyerror, hstore_scan.l:172
Other than that, I'm not sure in what sense you consider that jsonb is
"missing GIN/GiST". If you mean that it doesn't have some of the
capabilities that I believe are planned for the VODKA infrastructure
[1], which one might hope
On Thu, Feb 27, 2014 at 6:02 PM, Craig Ringer wrote:
> It's also make it a lot harder to use in other extensions, something
> that's already an issue with hstore.
What do you mean?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
stance
extension "requires" 'cube', for example, "a data type cube for
representing multidimensional cubes". Although I am aware of the
lengths that drivers like psycopg2 go to to support hstore because
it's an extension, which is undesirable.
--
Peter Geogheg
e really confusing error messages when
you go to create a GIN index. jsonb is no use on its own; why not just
make it all or nothing?
Another way of resolving this tension might be to push a lot more of
hstore into core than is presently proposed, but that seems like a
more difficult solution with little
On Thu, Feb 27, 2014 at 7:27 PM, Andrew Dunstan wrote:
> On 02/27/2014 10:09 PM, Peter Geoghegan wrote:
>
>> * It hardly makes any sense to have an in-core jsonb if it comes with
>> no batteries included. You need to install hstore for this jsonb
>> implementation t
pers trying to use it.
I'm not advocating authoring two extensions. I am tentatively
suggesting that we look at one extension for everything. That may well
be the least worst thing.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On Thu, Feb 27, 2014 at 8:07 PM, Peter Geoghegan wrote:
> On Thu, Feb 27, 2014 at 8:05 PM, Stephen Frost wrote:
>> And, for my 2c, I'd like to see jsonb as a built-in type *anyway*. Even
>> if it's possible to fight with things and make inter-extension
>> depend
On Thu, Feb 27, 2014 at 8:23 PM, Christophe Pettus wrote:
> On Feb 27, 2014, at 8:04 PM, Peter Geoghegan wrote:
>
>> I'm hearing a lot about how important jsonb is, but not much on how to
>> make the simple jsonb cases that are currently broken (as illustrated
>> b
e concerned about finding
*some* way of integrating jsonb that is broadly acceptable.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
sting putting all of hstore in core, because
jsonb and hstore are approximately the same thing. That seem quite a
bit more controversial than putting everything in the hstore
extension. I doubt that you can reasonably take any half measure
between those two extremes, and one seems a lot less co
On Thu, Feb 27, 2014 at 11:02 PM, Christophe Pettus wrote:
> On Feb 27, 2014, at 9:59 PM, Peter Geoghegan wrote:
>> I don't find that very reassuring.
>
> Obviously, we have to try it, and that will decide it.
I don't think that's obvious at all. Anyone is free to
t
them submit it. I maintain that the *current* state of affairs, where
jsonb isn't sure if it's in core or is an extension will not fly.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Feb 28, 2014 at 12:01 AM, Andres Freund wrote:
> On 2014-02-27 23:54:47 -0800, Peter Geoghegan wrote:
>> In any case, as I say, if that's the patch that Andres or Oleg or
>> Teodor really want to submit, then by all means let them submit it.
>
> Just to make t
On Fri, Feb 28, 2014 at 5:01 AM, Andrew Dunstan wrote:
> But anyway, I think we've seen enough of these to conclude that the casts
> from hstore to jsonb and back should not be implicit. I am fairly confident
> that changing that would fix your complaint and the similar one that Pet
at's true. I used to work as a consultant, and I had a
number of fairly conservative clients. I don't ever recall there being
a restriction on installing a contrib package. If indeed any DBA does
operate under such a restrictive regime, then that's probably not the
kind of
m that something is
> in -contrib can very well be telling them "You can't have it" in those cases.
Amazon RDS Postgres has hstore.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
tore ones, which work fine. But, if we didn't run out of time,
how would the jsonb operator classes differ from the hstore ones? Is
there something inferior about the hstore operator class as compared
to a hypothetical jsonb operator class, other than the superficial
need to cast?
--
Peter
that the
point? When there is a dedicated set of jsonb operator classes, what
will be different about them, other than the fact that they won't be
hstore operator classes? A decision predicated on waiting for those to
come in 9.5 must consider what we're actually waiting for, and righ
On Fri, Feb 28, 2014 at 2:40 PM, Christophe Pettus wrote:
> On Feb 28, 2014, at 2:12 PM, Peter Geoghegan wrote:
>
>> AFAICT, we have these
>> operator classes that work fine with jsonb for the purposes of
>> hstore-style indexing (the hstore operator classes).
>
quot;Enables/disables the
> use of huge memory pages".
Whenever I wish to emphasize that distinction, I tend to use the term
"MMU pages".
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
arly guarded about sharing the information.
Why do you think that hash indexes still aren't WAL-logged after all
these years (a project that someone made noise about recently in
relation to GSoC), even though that's generally considered to be a
SMOP?
--
Peter Geoghegan
--
Sent via pg
On Fri, Feb 28, 2014 at 2:12 PM, Peter Geoghegan wrote:
> In order to make a rational decision to do the work incrementally, we
> need to know what we're putting off until 9.5. AFAICT, we have these
> operator classes that work fine with jsonb for the purposes of
> hstore-st
On Mon, Mar 3, 2014 at 4:57 PM, Josh Berkus wrote:
> On 03/03/2014 04:50 PM, Peter Geoghegan wrote:
>> I understand that there are ambitious plans for a VODKA-am that will
>> support indexing operations on nested structures that are a lot more
>> advanced than those enabled b
On Mon, Mar 3, 2014 at 5:09 PM, Josh Berkus wrote:
> On 03/03/2014 05:07 PM, Peter Geoghegan wrote:
>>> Primary value is that in theory the hstore2 opclasses are available
>>> *now*, as opposed to a year from now.
>>
>> Well, yes, that's right. Althoug
e, but it's not our immediate concern. We need to
think very hard about it to get everything we want, but we also need
to think somewhat harder about it in order to get even a basic jsonb
type committed.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Mar 3, 2014 at 7:39 PM, Peter Geoghegan wrote:
>> But that's really just a start. Frankly, I think we need to
>> think a lot harder about how we want to be able to index this sort of data.
>> The proposed hstore operators appear to me to be at best just scratching
sensus? In
what way are we changing course? I think I'm being eminently flexible.
I don't want a jsonb type that is broken, as for example by not having
a default B-Tree operator class. Why don't you let me get on with it?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing li
On Mon, Mar 3, 2014 at 9:05 PM, Andrew Dunstan wrote:
> What you're not welcome to do, from my POV, is move jsonb into the hstore
> extension. I strenuously object to any such plan.
We both know that that isn't really the point of contention at all.
--
Peter Geoghegan
--
e type AFAICT. Enums took us two or three releases to get
> to where we are. Arrays took longer. Even a smallish feature like CSV import
> is still being tweaked about seven releases after it was introduced.
My objection is that the cost/benefit analysis behind the idea of
excluding the hstore operator classes seem to make no sense.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,
"postalCode": 10021, "streetAddress": "21 2nd Street"}, "lastName":
"Smith", "firstName": "John", "phoneNumbers": [{"type": "home",
"number": "212 555-1234"}, {"type": "fax", "number": "646 555-4567"}]}
Time: 6.479 ms
[local]/postgres=# explain select * from bar where i @> '{"age":25.0}'::jsonb;
QUERY PLAN
-
Seq Scan on bar (cost=0.00..26.38 rows=1 width=32)
Filter: ((i)::hstore @> '"age"=>25.0'::hstore)
Planning time: 0.154 ms
(3 rows)
Time: 6.565 ms
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
FUNCTION3 gin_extract_hstore_query(internal,
internal, int2, internal, internal),
+ FUNCTION4 gin_consistent_hstore(internal, int2,
internal, int4, internal, internal),
+ STORAGE text;
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgs
t; type) you need explicitly point type of compare to prevent unpredictable
> result.
That's what I meant, I think. But I'm not sure what you mean:
Native Chrome JavaScript.
Copyright (c) 2013 Google Inc
25 == 25
=> true
25 == 25.0
=> true
--
Peter Geoghegan
--
Sent
On Tue, Mar 4, 2014 at 2:18 AM, Teodor Sigaev wrote:
> That is because compareJsonbValue compares numeric values with a help of
> numeric_cmp() instead of comparing text representation. This inconsistent
> will be fixed.
Cool.
--
Peter Geoghegan
--
Sent via pgsql-hackers mai
On Tue, Mar 4, 2014 at 2:18 AM, Peter Geoghegan wrote:
> On Tue, Mar 4, 2014 at 2:18 AM, Teodor Sigaev wrote:
>> That is because compareJsonbValue compares numeric values with a help of
>> numeric_cmp() instead of comparing text representation. This inconsistent
>> wi
per. Isn't this
kind of thing intentionally not described by the relevant spec anyway?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
bad. I hope to have a
precise answer to just how bad soon.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
b']);
! slice
! -
! "b"=>2, "aa"=>1
(1 row)
select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b','aa']);
! slice
! -
! "b"=>2, "c"=&
will be
acceptable. The advantages of making a clean-break in having to
support the legacy hstore disk format strengthen the case for doing so
too.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
ay that makes it available to everyone
so much easier.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t would certainly be
interesting, though.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
GIN opclass:
https://github.com/feodor/postgres/commit/6f5e4fe9fc34f9512919b1c8b6a54952ab288640s
If it doesn't explain the problem, you may still wish to comment on
the correctness of this fix. I am still waiting on feedback from Oleg
and Teodor.
--
Peter Geoghegan
--
Sent via pgsq
On Mon, Mar 10, 2014 at 3:19 AM, Peter Geoghegan wrote:
> I don't have time to post that at the moment, but offhand I *think*
> your confusion may be due to the fact that the json_hash_ops opclass
> (as I call it) was previously consistent with the behavior of the
> other GIN opc
On Mon, Mar 10, 2014 at 3:21 AM, Peter Geoghegan wrote:
> Sorry, I realize now that that must be incorrect. Still, please take a
> look at the commit linked to.
To be clear, I mean that my explanation of why this was missed before
was incorrect, not my contention that it's a proble
On Mon, Mar 10, 2014 at 3:47 AM, Alexander Korotkov
wrote:
> Fix is attached.
Could you post a patch with regression tests, please?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
ious why the
requirements for those two things (the hashing mechanism used by the
jsonb_hash_ops GIN opclass, and the hash operator class support
function 1 hash function) cannot be the same thing.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
e open bug, and removes the least understood part of the code. The
GiST opclass is not particularly compelling for this.
--
Peter Geoghegan
--
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, Mar 11, 2014 at 4:41 PM, Peter Geoghegan wrote:
> I think that in practice the
> general recommendation will be that when indexing at the "top level",
> use jsonb_hash_ops. When indexing nested items, use the more flexible
> default GIN opclass. That seems like a pre
id upthread, if Postgres does that then it's because the
bytes you sent aren't what you think the are when rendered as UTF-8.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
n introduces, for example by using locking and
> atomic renames.
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
pose that the cost of the random I/O involved would
probably dominate just as with compress_backup_block = off. That said,
you've used an SSD here, so perhaps not.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
uld be that the
random I/O was so expensive that the additional cost of decompressing
the FPIs looked insignificant in comparison. If that was the case, the
increase in recovery time would be modest.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
enterprisedb.com
[6]
http://www.postgresql.org/message-id/1172858409.3760.1618.ca...@silverbirch.site
[7] http://www.postgresql.org/message-id/1132000496.3388.31.camel@holly
[8] http://www.postgresql.org/message-id/20083.1131730...@sss.pgh.pa.us
[9]
https://github.com/postgres/postgres/blob/REL9_3_STABLE/src/backend/access/nbtree/nbtinsert.c#L174
[10]
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=6868ed7491b7ea7f0af6133bb66566a2f5fe5a75
--
Peter Geoghegan
insert_on_dup.v1.2013_08_30.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Aug 30, 2013 at 3:40 PM, Josh Berkus wrote:
> Does this work with multiple VALUES rows?
Yes.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
1001 - 1100 of 3472 matches
Mail list logo
