? I kinda expected it to get committed right
after we opened 9.5.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/19/2014 01:03 PM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> On 11/12/2014 06:57 PM, Alvaro Herrera wrote:
>>>> How did template0 even get a MultiXact? That sounds like they're really
>>>> abusing the template databases. :( (Do keep in mind that MX
xact in any tuple's
> xmax, but datminxid is set to the value that is current when it is
> frozen.
>
So, to follow up on this: it seems to me that we shouldn't be requiring
freezing for databases where allowconn=false. This seems like a TODO to
me, even possibly a backpatchabl
On 11/18/2014 10:47 AM, Tom Lane wrote:
> Josh Berkus writes:
>> Since querying pg_locks can be intrusive due to needing to lock the lock
>> partitions, when I'm collecting data about locks I generally put a
>> statement_timeout on it. However, I'm noticing that th
un for up to 10 minutes* when the database is heavily loaded. This it
seems likely to me that the functions under pg_locks aren't checking for
interrupts. Anybody checked this already?
(yes, when a 64,000 item lock table is mostly full of locks, queries
against pg_locks *can* take 10 minut
> restart the replica, it's going to back up to the most recent
> restartpoint and begin replication from there, not from the point it
> was at when you shut down.
Except that in the problem case, it appears to be going *forwards*.
What would cause that?
--
Josh Berkus
PostgreSQL Exp
On 11/07/2014 02:03 PM, Josh Berkus wrote:
> But, like I said, there's a serviceable workaround.
Some update on this. We've seen a problem in production with this setup
which I can't reproduce as a test case, but which may jog Heikki's
memory for something to fix.
1. Re
On 11/10/2014 10:48 PM, Josh Berkus wrote:
> Hackers,
>
> I thought 9.4's postgresql.conf.sample was supposed to have a
> commented-out line for postgresql.auto.conf? In the "includes" section?
>
> It's not there. If we don't give folks a commented-ou
Hackers,
I thought 9.4's postgresql.conf.sample was supposed to have a
commented-out line for postgresql.auto.conf? In the "includes" section?
It's not there. If we don't give folks a commented-out line to
uncomment, it'll be pretty hard for them to figure out
On 11/09/2014 08:00 PM, Josh Berkus wrote:
On 11/08/2014 01:46 PM, Andres Freund wrote:
>> I'm these days suggesting that people should add manual vacuuming for
>> > "older" relations during off peak hours on busy databases. There's too
>> > many site
l.
>
> I'm these days suggesting that people should add manual vacuuming for
> "older" relations during off peak hours on busy databases. There's too
> many sites which service degrades noticeably during a full table vacuum.
Me too: https://github.com/pgexperts/flexi
On 11/07/2014 05:29 PM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> Of course, this will lead to LOTs of additional vacuuming ...
>
> There's a trade-off here: more vacuuming I/O usage for less disk space
> used. How stressed your customers really are about 1 GB of disk
d behavior.
Of course, this will lead to LOTs of additional vacuuming ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/05/2014 11:15 AM, Josh Berkus wrote:
> On 11/05/2014 10:40 AM, Jim Nasby wrote:
>> Can you post the contents of pg_multixact/members/?
>
> Well, not as of last week, obviously.
>
> https://gist.github.com/jberkus/d05db3629e8c898664c4
>
> I haven't pasted
On 11/07/2014 01:30 PM, Robert Haas wrote:
> On Fri, Nov 7, 2014 at 4:00 PM, Josh Berkus wrote:
>> In order for this to work, the archive would need to stop before
>> recovery_target_time.
>
> Yeah, good point. I didn't think of the case where you've rewound t
on
fails with "end of wal reached on timeline 1 320/478ff780; new timeline
2 forked timeline 1 before current recovery point 320/47e0".
In order for this to work, the archive would need to stop before
recovery_target_time.
On 11/07/2014 12:07 PM, Robert Haas wrote:> On Fri
r our current behavior is
correct or not. For my part, I would like to have a different
interacton, but I think that's a future feature rather than a bug, as
long as we do the stuff in the Yes column.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers ma
On 11/07/2014 08:12 AM, Robert Haas wrote:
> On Wed, Nov 5, 2014 at 9:15 PM, Josh Berkus wrote:
>> What I'm pointing out is that you can't actually do that. You think you
>> can, but you can't.
>
> I do think that. You haven't explained why I'm wr
On 11/05/2014 05:41 PM, Michael Paquier wrote:
> On Thu, Nov 6, 2014 at 10:00 AM, Greg Stark wrote:
>> On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus wrote:
>>> When the recovery_target_time is reached, switch to streaming
>>> replication and stay a standby.
>&
On 11/05/2014 05:00 PM, Greg Stark wrote:
> On Thu, Nov 6, 2014 at 12:32 AM, Josh Berkus wrote:
>> When the recovery_target_time is reached, switch to streaming
>> replication and stay a standby.
>
> Then shouldn't he just not specify a recovert_target at all? That
switch to streaming
replication and stay a standby.
Note that there is a workaround for what the user wants to do. I'm just
trying to clarify what our desired behavior is. From there we can
either work on patches or on doc fixes.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
On 11/05/2014 02:36 PM, philip taylor wrote:
> Ok, this is a summary of what they have that we don't (of course, I could
> have missed something):
>
I can't see any functions on that list I'd want.
For example, DATEADD is there just to be compatible with MSSQL. It&#x
On 11/05/2014 10:40 AM, Jim Nasby wrote:
> On 11/3/14, 7:40 PM, Josh Berkus wrote:
>> On 11/03/2014 05:24 PM, Josh Berkus wrote:
>>> BTW, the reason I started poking into this was a report from a user that
>>> they have a pg_multixact directory which is 21GB in size, an
it would make sense to do this for "timestamp", or
> whether there's even a clear intuitive behaviour there.
Why wouldn't we just add the timezone as an additional parameter?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
create versions that
don't have operator conflicts.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to xml2 again?
FWIW, I'd be fine with moving ISN, intarray and intagg to PGXN. In
fact, I think it would be better for them to be there. And they're not
core types, so there shouldn't be an issue with that.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent v
On 11/03/2014 05:24 PM, Josh Berkus wrote:
> BTW, the reason I started poking into this was a report from a user that
> they have a pg_multixact directory which is 21GB in size, and is 2X the
> size of the database.
>
> Here's XID data:
>
> Latest checkpoint's
On 11/03/2014 05:06 PM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> Hackers,
>>
>> I'm looking at a couple of high-transaction-rate and high-FK-conflict
>> rate servers where pg_multixact has grown to be more than 1GB in size.
>> One such server doesn&#x
FREEZEing the oldest databases did not cause the pg_multixact dir to get
smaller --- it may have even caused it to get larger.
Why would pg_multixact not be truncating? Does it never truncate files
with aborted multixacts in them? Might we have another multixact bug?
--
Josh Berkus
PostgreS
All,
While there's argument about hash indexes, it looks like nobody minds if
the MONEY type goes bye-bye. So, time for a patch ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
TABLE
> regression=# create index on foo using hash (f1);
> WARNING: hash indexes are not WAL-logged and their use is discouraged
> CREATE INDEX
Yes, and I'm arguing that is the wrong decision. If hash indexes are
"discouraged", then they shouldn't be in core in
ust about to fix WAL-logging on hash indexes, or add casts to
the money type. But if that hasn't happened in the last 5 years, it's
not going to happen.
We'd be doing our users a huge favor by just removing them in 9.5.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
ith peer and ident. Maybe someday
(protocol bump) we can have a way to make other methods continue, and
then nobody will need to change their files to support the new way.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
good
GSOC project or first-time contribution.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
se of us who haven't followed every post in this thread, is there
somewhere I can see the proposed syntax?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgr
#x27;s no reason we *have* to do anything other than set hint bits and
> possibly freeze xmin.
+1
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
CK,
Before we go any further on this, how is Vitesse currently licensed?
last time we talked it was still proprietary. If it's not being
open-sourced, we likely need to take discussion off this list.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-ha
27;t give our users any kind of reasonable
monitoring threshold at all sucks though. Also, it makes it kind of
hard to allocate a wal partition if it could be 10X the minimum size,
you know?
What happened to the work Heikki was doing on making transaction log
disk usage sane?
--
Josh Berkus
Postg
Ls partition.
If we don't count the WAL files, though, that eliminates the best way to
detecting when archiving is failing.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
All,
Crossing this over to -hackers because it's stopped being a bug and is
now a TODO item. See below.
For those not on pgsql-bugs, I've quoted the full bug report below my
proposal.
On 10/09/2014 12:36 PM, Josh Berkus wrote:
> Summary: pg_restore -n attempts to restore objects
this (and it seems like a good idea), we really,
really, really need to include some general system views which expose
the options in a user-friendly format (like columns, JSON or an array).
It's already very hard for users to get information about what
reloptions have been set.
--
Josh Ber
ll don't have any docs for this even if we
decided to accept the GUC? On that basis, I'd say accept the DEFINE and
punt the GUC to the next 9.5 Commitfest ... assuming someone wants to
write docs.
Heck, I might write them after some testing. But that testing won't
happen in time
to hack my way around and send patches to
> have it (the common answer) available in the next PostgreSQL release.
Great!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/30/2014 04:58 PM, FabrÃzio de Royes Mello wrote:
> On Tue, Sep 30, 2014 at 8:47 PM, Josh Berkus wrote:
>>
>> On 09/30/2014 04:16 PM, Andres Freund wrote:
>>> On 2014-09-30 16:03:01 -0700, Josh Berkus wrote:
>>>> On 09/30/2014 03:53 PM, Andres Freund w
On 09/30/2014 04:16 PM, Andres Freund wrote:
> On 2014-09-30 16:03:01 -0700, Josh Berkus wrote:
>> On 09/30/2014 03:53 PM, Andres Freund wrote:
>>> Good point. I think it's fair enough to only allow CINE on named
>>> indexes.
>>
>> On the other han
On 09/30/2014 03:53 PM, Andres Freund wrote:
> On 2014-09-30 18:47:24 -0400, Tom Lane wrote:
>> Josh Berkus writes:
>>> On 09/30/2014 02:43 PM, Tom Lane wrote:
>>>> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
>>>>> What's your thoughts
do think it should be name-based. While an "IF NOT EXISTS" which
checked for a duplicate column declartion would be nice, there's a raft
of issues with implementing it that way. Users I know are generally
just looking to avoid getting a transaction-halting error when they run
the sa
On 09/30/2014 02:51 PM, Kevin Grittner wrote:
> Josh Berkus wrote:
>> On 09/30/2014 02:39 PM, Kevin Grittner wrote:
>>> Josh Berkus wrote:
>>>> On 09/30/2014 07:15 AM, Kevin Grittner wrote:
>>>>
>>>>> At the risk of pushing people away
On 09/30/2014 02:39 PM, Kevin Grittner wrote:
> Josh Berkus wrote:
>> On 09/30/2014 07:15 AM, Kevin Grittner wrote:
>
>>> At the risk of pushing people away from this POV, I'll point out
>>> that this is somewhat similar to what we do for unlogged bulk loa
een fast/slow bulk loads affects *only* the
speed of loading, not the locking rules. Having a statement silently
take a full table lock when we were expecting it to be concurrent
(because, for example, the index got rebuilt and someone forgot the
UNIQUE) violates POLA from my perspecti
27;s blocking it then fine. But if we might change the
concurrency approach, then what's the point in quibbling about docs?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
dly anything which should block the patch. It has
documentation, more than we'd require for a lot of other patches, and
it's not like the 9.5 release is next month.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hacker
gt; actually write the documentation and commit it that way, I'm happy with
> that too.
I'm also in favor of removing it. We really don't need more GUCs which
nobody has any clear idea how to change or why.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via p
On 09/29/2014 11:49 AM, Arthur Silva wrote:
> What's the call on the stride length? Are we going to keep it hardcoded?
Please, yes. The complications caused by a variable stride length would
be horrible.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql
UCs" curmudgeon hat.
1. What does it do?
2. Are there reasons why users would want to change it from the default?
3. Can we explain those reasons in the form of documentation?
IMHO, if the answers to 2 or 3 are "no", then we shouldn't have a GUC.
--
Josh Berkus
PostgreSQL E
On 09/26/2014 06:20 PM, Josh Berkus wrote:
> Overall, I'm satisfied with the performance of the length-and-offset
> patch.
Oh, also ... no bugs found.
So, can we get Beta3 out now?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing
ngth-and-offset when uncompressed (EXTERNAL) was faster on
Q1 than head! This was surprising enough that I retested it.
Overall, I'm satisfied with the performance of the length-and-offset
patch.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers ma
"round to nearest", but the two changes can be considered
> independently.
I'm good with the error. We'll want to add stuff to both the docs and
pg_settings to *show* the minimum value, and an informative error
message would help, i.e.:
"Invalid value for log_rotation_i
n-zero, as it would then be rounded to zero.
That would not be a back-portable fix.
There are many 3rd-party tools out there (AWS RDS, for one) which do not
use the units.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
ving up a couple percent of space in comparison to the
> all-lengths version, but this is probably an acceptable tradeoff
> for not degrading on very large arrays.
>
> I've not done any speed testing.
I'll do some tommorrow. I should have some different DBs to test on, too.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ll us anything we
> don't expect, but we should do it anyway.
OK. I'll spend some time trying to get Socorro with JSONB working so
that I'll have a second test case.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hack
On 09/25/2014 10:26 AM, Andres Freund wrote:
> On 2014-09-25 10:25:24 -0700, Josh Berkus wrote:
>> If Heikki says it's ready, I'll test. So far he's said that it wasn't
>> done yet.
>
> http://www.postgresql.org/message-id/541c242e.3030...@vmware.com
Ye
On 09/25/2014 10:20 AM, Andres Freund wrote:
> On 2014-09-25 10:18:24 -0700, Josh Berkus wrote:
>> On 09/25/2014 10:14 AM, Bruce Momjian wrote:
>>> On Thu, Sep 25, 2014 at 06:01:08PM +0200, Andres Freund wrote:
>>>> But independent of which version is chosen
e for releasing based on Tom's lengths-only
patch, which is done, tested, and ready to go.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/25/2014 09:01 AM, Andres Freund wrote:
> But independent of which version is chosen, we *REALLY* need to make the
> decision soon. This issue has held up the next beta (like jsonb has
> blocked previous beta) for *weeks*.
Yes, please!
--
Josh Berkus
PostgreSQL Experts
commits it.
That's certainly what it looks like to me, and on that basis Stephen
should have held back the patch until he got reviewer OK.
Fortunately, since we use Git and not CVS, reverting patches isn't the
trauma it once was.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
ately reviewed (and if not, if it should be reverted),
not whether it should have been in the CF or not.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
~15
> years since the last release.
> Since there's both msvc and mingw support for windows builds - borlands
> only platform - I see little point in continuing to support it.
+1
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql
are we on this? Do we have a patch ready for testing?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t can do more to help us with the
> testing and review process.
We discussed this at the last developer meeting, without coming up with
a written procedure. Your ideas can help ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> - []
>
> Would that be better? (It's not consistent with other YAML outputs like
> sort/group keys, but it's equally legal as far as I can tell and seems
> more readable.)
That works for me.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sen
before reading this :)
>>
>> I guess it proves (a little) that WITH is the right place to do these
>> kind of things ...
>
> I've been wanting this syntax for a few years now, so I certainly vote
> for it.
>
Just to clarify: I want the WITH syntax for different
nc(x,y,z);
Oh! Awesome!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
engths patch so that we can get 9.4 out
the door.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
]
.. in JSON?
Seems to me that we need a better way to display the grand total
grouping set.
>
> Or maybe:
>Grouping Set: (onek.four, onek.ten, onek.hundred)
>Grouping Set: (onek.four, onek.ten)
>Grouping Set: (onek.four)
>Grouping Set: ()
The lat
ess well, and we've got an approach that fixes that
> problem while preserving the advantages of fast lookup. We should
> have a darn fine reason to say no to that approach, and "it didn't
> benefit my particular use case" is not it.
Do you feel that way *as a code maint
f using PostgreSQL arrays; I had to test it to
verify the current behavior.
Not sure exactly where this note should go, mind you.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/16/2014 09:54 AM, Robert Haas wrote:
> On Tue, Sep 16, 2014 at 12:47 PM, Josh Berkus wrote:
>> On 09/16/2014 06:31 AM, Robert Haas wrote:
>>> On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan wrote:
>>>> On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus wrote:
&
On 09/16/2014 06:31 AM, Robert Haas wrote:
> On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan wrote:
>> On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus wrote:
>>> Actually, having the keys all at the same level *is* relevant for the
>>> issue we're discussing. If t
On 09/15/2014 02:16 PM, Robert Haas wrote:
> On Mon, Sep 15, 2014 at 3:09 PM, Josh Berkus wrote:
>> On 09/15/2014 10:23 AM, Claudio Freire wrote:
>>> Now, large small keys could be 200 or 2000, or even 20k. I'd guess
>>> several should be tested to find the shape o
On 09/15/2014 12:25 PM, Claudio Freire wrote:
> On Mon, Sep 15, 2014 at 4:17 PM, Josh Berkus wrote:
>> On 09/15/2014 12:15 PM, Claudio Freire wrote:
>>> So while you're right that it's perhaps above what would be a common
>>> use case, the range "somew
On 09/15/2014 12:15 PM, Claudio Freire wrote:
> So while you're right that it's perhaps above what would be a common
> use case, the range "somewhere between 200 and 100K" for the tipping
> point seems overly imprecise to me.
Well, then, you know how to solve that
th testing further if we think that
having more than 200 top-level keys in one JSONB value is going to be a
use case for more than 0.1% of our users. I personally do not.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
why your patch
would be faster for the "last element" case than the original offsets
version?
If not, I think the corner case is so obscure as to be not worth
optimizing for. I can't imagine that more than a tiny minority of our
users are going to have thousands of keys per datum.
-
On 09/12/2014 01:33 PM, Tom Lane wrote:
> Josh Berkus writes:
>> However, this better become a FAQ item, because it's not necessarily the
>> behavior that folks used to JSON but not Postgres will expect.
>
> No, it's a bug, not a documentation deficiency.
Hmmm? A
---
t
That's consistent with our docs and past behavior.
However, this better become a FAQ item, because it's not necessarily the
behavior that folks used to JSON but not Postgres will expect.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hacker
e weird :)
> The reason why jsonb contains behaves so is check in the beginning
> of jsonb_contains. It makes fast check of jsonb type and elements count
> before calling JsonbDeepContains.
>
> if (JB_ROOT_COUNT(val) < JB_ROOT_COUNT(tmpl) ||
> JB_ROOT_IS_OBJECT(val) != JB_ROOT
On 09/12/2014 10:00 AM, Robert Haas wrote:
> On Fri, Sep 12, 2014 at 1:00 PM, Robert Haas wrote:
>> On Thu, Sep 11, 2014 at 9:01 PM, Josh Berkus wrote:
>>> So, I finally got time to test Tom's latest patch on this.
>>>
>>> TLDR: we want to go
ire-hose data.
Yah, if we have enough time for me to get the Mozilla Socorro test
environment working, I can also test with Mozilla crash data. That has
some deep nesting and very large values.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (p
t JSONB columns to EXTERNAL, and the
the same performance as the unpatched version.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
sors that they work *exactly* like
PL/SQL's packages, which is incompatible with Postgres namespacing.
Also, we'd want any "package" concept to be usable with external PLs as
well as PL/pgSQL, which necessitates other Oracle-incompatible changes.
--
Josh Berkus
PostgreSQL Experts Inc.
On 09/02/2014 03:19 PM, Josh Berkus wrote:
> Well, if I were designing a new procedural SQL extension language, I
> wouldn't base it on the bastard child of ADA and SQL89. I would come up
Ada, that is. One is a programming language, the other is the bane of
architects.
--
amount to the proverbial porcine
makeover.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
tension.
On the other hand, I take partial responsibility for the mess which is
our data type naming. What we call timestamptz should just be
"timestamp", and whether or not it converts to local timezone on
retrieval should be a GUC setting. And the type we call "timestamp"
sh
; : { "parameters" : { "$1" : 90700 } }
...
This would allow me, or Dalibo, to remove literally dozens of lines of
error-prone regexing code.
That fix would, IMHO, make it worth enabling JSON logging as a logging
hook or something similar. If we're just going to convert the C
On 08/28/2014 09:09 AM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> On 04/16/2014 01:30 PM, Alvaro Herrera wrote:
>>> Josh Berkus wrote:
>>>>
>>>>> You can see the current multixact value in pg_controldata output. Keep
>>>>> tim
storage.
Testing STORAGE EXTENDED soon.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08/26/2014 11:40 AM, Tom Lane wrote:
> Josh Berkus writes:
>> Anyway, I called for feedback on by blog, and have gotten some:
>> http://www.databasesoup.com/2014/08/the-great-jsonb-tradeoff.html
>
> I was hoping you'd get some useful data from that, but so far i
it's an order-of-magnitude slower.
Anyway, I called for feedback on by blog, and have gotten some:
http://www.databasesoup.com/2014/08/the-great-jsonb-tradeoff.html
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
IO while it works to write out all of RAM, which makes me
suspect you're using Ext3 or HFS+.
Making the bgwriter more aggressive adds a significant risk of writing
the same pages multiple times between checkpoints, so it's not a simple fix.
--
Josh Berkus
PostgreSQL Experts Inc.
http://p
501 - 600 of 5051 matches
Mail list logo
