in tablespace "ssd"
HINT: You must move them back to the database's default tablespace
before using this command.
Aside from being a stupid limitation (I need to copy the tables back to
the old tablespace so that I can recopy them to the new one?), the above
seems to be in direct con
On 08/20/2014 03:42 PM, Arthur Silva wrote:
> What data are you using right now Josh?
The same data as upthread.
Can you test the three patches (9.4 head, 9.4 with Tom's cleanup of
Heikki's patch, and 9.4 with Tom's latest lengths-only) on your workload?
I'm concer
On 08/20/2014 08:29 AM, Tom Lane wrote:
> Josh Berkus writes:
>> On 08/15/2014 04:19 PM, Tom Lane wrote:
>>> Personally I'd prefer to go to the all-lengths approach, but a large
>>> part of that comes from a subjective assessment that the hybrid approach
>
N^2) penalties in findJsonbValueFromContainer and
> JsonbIteratorNext
OK, will test.
This means we need a beta3, no?
--
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:
ime: 0.095 ms
Execution time: 5292.047 ms
(7 rows)
So, that extraction test is about 1% *slower* than the basic Tom Lane
lengths-only patch, and still 80% slower than original JSONB. And it's
the same size as the lengths-only version.
Huh?
--
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
ince it's in the examples, people will
> probably use it, even if they don't need to or shouldn't. And not
> recommending it for the restore_command is also confusing.
I'm afraid that I agree with Peter here. pg_copy looks like a nice
foundation for the eventual
e
pattern of having between 50 and 200 keys, each of which has a short value.
So we don't need to *optimize* for that case, but it also shouldn't be
disastrously slow or 300% of the size of comparable TEXT. Mind you, I
don't find +80% to be disastrously slow (especially not with a spac
case, the *index* on the
JSONB is only 60MB. Which shows just how terrific the improvement in
GIN index size/performance is.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
t;2003-06-30"}'::jsonb)
Planning time: 0.098 ms
Execution time: 5214.212 ms
... so, an 80% increase in lookup and extraction time for swapping
offsets for lengths. That's actually all extraction time; I tried
removing the extraction from the query, and without it both queries are
close enough to be statstically insignificant.
--
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
cases for which automated connection failover without a
managed proxy is a Seriously Bad Idea. For one thing, you're setting up
a strong risk of split-brain.
--
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/14/2014 04:47 PM, Josh Berkus wrote:
> thetype |colsize_distribution
> -+
> json| {1777,1803,1890,1940,4424}
> jsonb | {5902,5926,5978,6002,6208}
Just realized my query was counting the whole row size instead of just
the column s
json| {1777,1803,1890,1940,4424}
jsonb | {5902,5926,5978,6002,6208}
Shouldn't the lower end stuff be smaller?
--
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/14/2014 04:02 PM, Tom Lane wrote:
> Josh Berkus writes:
>> So, here's a destruction test case:
>> 200,000 JSON values (plus 2 key columns)
>> Average width 4K (+/- 1K)
>> 183 keys per JSON value
>
> Is that 183 keys exactly each time, or is 183 the av
e_pretty
----
11 MB
(1 row)
Next up: Tom's patch and indexing!
--
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
ce the whitespace and syntax
> sugar is gone in JSONB, I was unclear how much compression would help.
I thought the destruction case was when we have enough top-level keys
that the offsets are more than 1K total, though, yes?
So we need to test that set ...
--
Josh Berkus
PostgreSQL Experts
to fix the compression without rewriting all their data,
which could be prohibitive. And we'll be in a position where we have
to support the 9.4 JSONB format/compression technique for years so that
users aren't blocked from upgrading.
--
Josh Berkus
PostgreSQL Experts Inc.
http:
?
No review, but thank you for doing this!
--
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/07/2014 05:52 PM, Michael Paquier wrote:
> On Fri, Aug 8, 2014 at 9:47 AM, Josh Berkus wrote:
>> On 08/07/2014 08:38 AM, Oleg Bartunov wrote:
>>> +1 for BRIN !
>>>
>>> On Thu, Aug 7, 2014 at 6:16 PM, Simon Riggs wrote:
>>>> On 7 Augu
locks (not just one block). Perhaps a better one
>> would be simply "range index", which we could abbreviate to RIN or
>> BRIN.
How about Block Range Dynamic indexes?
Or Range Usage Metadata indexes?
You see what I'm getting at:
BRanDy
RUM
... to keep with our "ne
. There has been some talk of trying
> to do such coercions via SQL casts, but nothing's been done for fear
> of compatibility problems.
Yeah, that's a weeks-long project for someone. And would require a lot
of tests ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
ag set. If you tried to use += with other
> variables, an error would be raised.
Yes.
BTW, while there's unlikely to be a good reason to put search_path in
pg.conf with appends, there are a LOT of reasons to want to be able to
append to it during a session.
--
Josh Berkus
PostgreSQL Expe
else when
> implementing new database features".
Plus we haven't come up with a better name ...
--
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
ries, I can't think of a GUC
which would benefit from this. Can 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
one the default.
I always assumed that the current behavior existed because we *couldn't*
fix it, not because anybody wanted it.
--
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
hen I'd probably side with
Mike. However, it's hard for me to believe that this change is worth
breaking backwards compatibility.
--
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
ng if it couldn't
archive; there are reasons why a user might not care that
archive_command was failing (shared storage comes to mind). However,
that would be a surprising break with backwards compatability, since
currently users don't check the result value of pg_stop_backup().
Thoughts?
Was this issue ever resolved?
We are now having Nagios checks failing due to the pg_size_pretty function,
and the check runs fine on my local machine 9.1 (fails on 9.2 and 9.3, both
having two pg_size_pretty functions).
Thanks,
Josh
--
View this message in context:
http://postgresql.1045698
> postgresql.conf
> has an invalid setting.
> 5. Failover on shared-disk HA configuration happens, then PostgreSQL fails to
> start up because of such an invalid setting. When PostgreSQL
> starts up, the last
> setting is preferred. But all the settings are che
to initdb. Or use pg_upgrade to upgrade
> the cluster. We had to change pg_control format post-beta1.
Thank you for testing that though!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
ved on the file
> itself, or some other catalog, like a "trusted metadata" implemented
> by pg itself, and it could be an LSN range instead of a timestamp
> really.
What about requiring checksums to be on instead, and checking the
file-level checksums? Hmmm, wait, do we have
e of BDR only,
because everyone else will be afraid to touch it.
If this means that we need to finally create pg_editcontroldata, then so
be it.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
t notices for those. Well, maybe not for
fillfactor.
--
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
REINDEXed"
otherwise, we're going to get a lot of "I Altered the pages per range,
but performance didn't change" emails.
--
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
pdateValues". Very ... NoSQL-ish. "Maybe update
the values, maybe 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
On 07/08/2014 06:10 PM, Mark Kirkwood wrote:
> On 09/07/14 05:13, Josh Berkus wrote:
>> On 07/06/2014 01:27 AM, Christoph Berg wrote:
>>> Another could be that during initdb all the uncommented settings be
>>>> written to postgresql.auto.conf file rather than to po
three reasons:
1) Some users will copy over their older pg.conf's to 9.4, which will
already have shared_buffers uncommented;
2) Some distros ship their own pg.conf;
3) Doesn't solve the issue of overlapping files in conf.d, which is the
same problem.
--
Josh Berkus
PostgreSQL Expe
ers should stick to
one or the other method of management (or, thirdly, using conf.d); if
they mix methods, we can't prevent confusion at restart time and we
shouldn't try.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-h
a second pass, enforce requirements like "can't be
> changed except at server start".
+1
This would also make conf.d much more useful; I wouldn't have to worry
as much about overlapping config settings.
Sounds like a 9.5 feature, though.
--
Josh Berkus
PostgreSQL Experts
Abjit, all:
If we're adding log_line_prefix support for cluster_name (something I
think is a good idea), we need to also add it to CSVLOG. So, where do
we put it in CSVLog?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-ha
On 06/25/2014 10:14 AM, Andres Freund wrote:
> Hi,
>
> [sorry for the second copy Robert]
>
> Attached is a new version of the atomic operations patch. Lots has
> changed since the last post:
Is this at a state where we can performance-test it yet?
--
Josh Berkus
PostgreSQL
On 06/24/2014 10:17 AM, Tom Lane wrote:
> Josh Berkus writes:
>> On 06/23/2014 03:52 PM, Andres Freund wrote:
>>> True. Which makes me wonder whether we shouldn't default this to
>>> something non-zero -- even if it is 5 or 10 days.
>
>> I'd go for
out, the local transaction is doomed (and won't
> even know it until it tries to commit). If we don't allow the fdw to be
> special, then the local transaction can't run at all. Ever.
I'm unclear on how the FDW could be special. From the point of the
remote server, how does it
convinced that anyone is ever going to write the
"cancel" version, can we please just leave the 2nd GUC out for now?
>>> A long idle in transaction state pretty much always indicates a
>>> problematic interaction with postgres.
>>
>> True. Which makes me w
s before
being addressed, I'm not convinced that we need to worry about what an
eventual error vs. fatal timeout should be named or how it should be
scoped. Let's attack that when someone actually shows an inclination to
work on it.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pge
about somebody complaining that
> that's not enough resolution, especially as machines get faster.
I can picture a 500ms timeout more readily than I can picture a 1000hr
timeout.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pg
On 06/19/2014 02:44 PM, Kevin Grittner wrote:
> Josh Berkus wrote:
>
>> Also, I really hope that nobody is setting this to 10s ...
>
> Well, we get to decide what the minimum allowed value is. What do
> you think that should be?
1s?
I don't think that setting it
orting the transaction is currently a
nonstarter. So no need for a 2nd GUC.
Also, I really hope that nobody is setting this to 10s ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
On 06/18/2014 04:54 PM, Marko Tiikkaja wrote:
> On 2014-06-19 1:46 AM, Josh Berkus wrote:
>> Robert's right, not killing the "BEGIN;" only transactions is liable to
>> result in user confusion unless we label those sessions differently in
>> pg_stat_act
works which do an automatic BEGIN; also
do other stuff like SET TIMEZONE each time as well. Is this really a
case worth worrying about?
--
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 06/18/2014 12:32 PM, Tom Lane wrote:
> Josh Berkus writes:
>> There are plenty of badly-written applications which "auto-begin", that
>> is, they issue a "BEGIN;" immediately after every "COMMIT;" whether or
>> not there's any addition
ing that any follow-up version
> requires some way to deal with the issues raised regarding multiple
> ERROR messages.
+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
Or are you saying that we have to destroy the data by resetting the xlog
before we can change the system identifier? If so, this feature is less
than completely useful ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
re independent, it would have to copy quite some code
> from pg_resetxlog.
Aha. In that case, it seems like it's time to rename pg_resetxlog, if
it does a bunch of things that aren't resetting the xlog.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via
etter design to have an independant function,
"pg_set_system_identifier"?
--
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 06/17/2014 02:53 PM, Tom Lane wrote:
> Josh Berkus writes:
>> On 06/17/2014 02:36 PM, Tom Lane wrote:
>>> Another issue is whether to print only those having exactly the minimum
>>> observed Levenshtein distance, or to print everything less than some
>>> c
On 06/17/2014 02:36 PM, Tom Lane wrote:
> Josh Berkus writes:
>> (2) If there are multiple columns with the same levenschtien distance,
>> which one do you suggest? The current code picks a random one, which
>> I'm OK with. The other option would be to list all of th
ing box minmax falls under the heading of "would be
nice to have, but not if it delays the feature".
--
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
for the sake of the
children, let's not have a GUC for it.
(2) If there are multiple columns with the same levenschtien distance,
which one do you suggest? The current code picks a random one, which
I'm OK with. The other option would be to list all of the columns.
--
Josh Berkus
test coming up.
Question: How should we handle the issues with East Asian languages
(i.e. Japanese, Chinese) and this Hint? Should we just avoid hinting
for a selected list of languages which don't work well with levenshtein?
If so, how do we get that list?
--
Josh Berkus
PostgreSQL Ex
r words, what I'm saying is: I don't think there's an existing,
poplular syntax we could reasonably use.
--
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 have to deal with the old ones for some time to come.
--
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 06/06/2014 03:23 PM, David E. Wheeler wrote:
> On Jun 6, 2014, at 12:51 PM, Josh Berkus wrote:
>> Well, I'd also say that we don't care about syntaxes which are not
>> already popular. There's no point in being compatible with something
>> nobody uses. H
y
syntax, and jsquery will be different enough to trip people up.
> I do think that the name should be changed if we don’t follow an existing
> standard, as [JSQuery](https://code.google.com/p/gwtquery/wiki/JsQuery) is
> already a thing.
I saw that too, but I don't get the impres
All,
Can we get this patch going again for 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 06/03/2014 02:53 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Out of curiosity, how much harder would it have been just to abort the
>> transaction? I think breaking the connection is probably the right
>> behavior, but before folks start arguing it out, I wanted to kn
logs so it can be graphed by things like pgbadger.
>
> Unfortunately, no notification is sent to the client because there's no
> real way to do that right now.
Well, if you abort the connection, presumably the client finds out when
they try to send a query ...
--
Josh Berkus
P
what you think it does", akin to what happens today with
> a drop-and-recreate-everything approach. 'CASCADE' might not be
> sufficient to meet that, maybe 'CASCADE REBUILD' or something?
I think CASCADE is sufficient; what else could a user mean by ALTER
TABLE ... C
reate a database named "foo / bar", I'll get a
complaint like:
ERROR: could not open "pg_hibernator/5.foo / bar.save": No such file
or directory
during shutdown.
Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, May 29, 2014 at 4:06 PM, Andrew Dunstan wrote:
> On 05/29/2014 02:38 PM, Tom Lane wrote:
>> Josh Kupershmidt writes:
>> Interesting. Looks like you have access only to virtual network
>> interfaces, and they report all-zero MAC addresses, which the UUID library
ant to the bug), and nothing of interest for gist index,
> although it only tested "where text_array @@ to_tsquery(?)" queries.
This is awesome. Thanks for doing it!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
ing to execute uuid_generate_v1() and see what the kernel interaction
> looks like exactly.
Here's the result of attaching strace to an idle backend, then running
SELECT uuid_generate_v1(). AFAIR shearwater is a cheaply-hosted OpenVZ
VPS under the hood.
Josh
josh@ease1:~$ strace -p 6818
haven't bothered with semicolon line terminators would break.
What if we make using semicolons or not a config option in the file? i.e.:
\multiline
--
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 05/20/2014 12:38 PM, Andres Freund wrote:
> On 2014-05-20 12:33:20 -0400, Josh Berkus wrote:
>> On 05/20/2014 12:07 PM, Alvaro Herrera wrote:
>>> Josh Berkus wrote:
>>>> I can't find the thread now, but I'm pretty sure that we decided to
>>>
On 05/20/2014 12:07 PM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> I can't find the thread now, but I'm pretty sure that we decided to
>> change the name of pg_recvlogical, because its inconsistent with other
>> client utils? No?
>
> There are other
I can't find the thread now, but I'm pretty sure that we decided to
change the name of pg_recvlogical, because its inconsistent with other
client utils? No?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
minal.
You'll get more help on the DBT mailing list, which I see you've already
found.
Are you doing this for a GSOC project? If so, what problem are you
trying to solve with it?
BTW, it's not very friendly to cross-post to 3 mailing lists at the same
time.
--
Josh Berku
How can this be? We're bundling a beta in 2 days.
--
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 04/26/2014 12:39 PM, Jim Nasby wrote:
> On 4/17/14, 6:42 PM, Josh Berkus wrote:
>> So we have some software we've been procrastinating on OSS'ing, which
>> does:
>>
>> 1) Takes full query CSV logs from a running postgres instance
>> 2) Runs them
on for most people (actually btree indexes are normally very
> fast).
What's "index maintenance"?
--
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 05/07/2014 01:36 PM, Jeff Janes wrote:
> On Wed, May 7, 2014 at 11:04 AM, Josh Berkus wrote:
>> Unfortunately nobody has the time/resources to do the kind of testing
>> required for a new recommendation for shared_buffers.
> I think it is worse than that. I don't
On 05/07/2014 11:52 AM, Peter Geoghegan wrote:
> On Wed, May 7, 2014 at 11:40 AM, Josh Berkus wrote:
>> So, as one of several people who put literally hundreds of hours into
>> the original benchmarking which established the sizing recommendations
>> for shared_buffers (a
can usefully participate in this discussion.
--
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
e_cache_size is supposed to
> represent. In general, the folk wisdom around sizing shared_buffers
> has past its sell-by date.
Unfortunately nobody has the time/resources to do the kind of testing
required for a new recommendation for shared_buffers.
--
Josh Berkus
PostgreSQL
On 05/07/2014 07:31 AM, Andrew Dunstan wrote:
> +1. If we ever want to implement an auto-tuning heuristic it seems we're
> going to need some hard empirical evidence to support it, and that
> doesn't seem likely to appear any time soon.
4GB default it is, then.
--
Jos
ob. This means that we can make large adjustments in it
without introducing a lot of highly variable behavior ... instead of
random_page_cost, which does.
--
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
pectives that you don't
really believe in is *definitionally* trolling. If you're going to make
an argument in favor of different tuning advice, then do it based on
something in which you actually believe, based on hard evidence.
--
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
d_buffers
I think the current cost math does a pretty good job of choosing the
correct behavior if ECS is set correctly. But if it's not, no.
If I'm wrong, then you've successfully found a bug in our costing math,
so I'd love to see it.
--
Josh Berkus
PostgreSQL Experts Inc.
h
On 05/05/2014 11:53 AM, Tom Lane wrote:
> Sure. They should all keep them outside $PGDATA, making it not-our-
> problem. When and if we're prepared to consider it our problem, we
> will be sure to advise people.
OK.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
I was
relying on pg_stat_replication to point out when a successful
replication connection was established. However, he pointed out cases
where pg_stat_replication will report sync or streaming even though
replication has failed due to differences in WAL position. That appears
to be what happene
On 05/05/2014 11:31 AM, Bruce Momjian wrote:
> JSONB values are also mapped to SQL scalar data types, rather
> than being treated always as strings.
+ ... allowing for correct sorting of JSON according to internal datums.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexper
On 05/05/2014 10:53 AM, Tom Lane wrote:
> Josh Berkus writes:
>> I'm working with the cstore_fdw project, which has an interesting
>> property for an FDW: the FDW itself creates the files which make up the
>> database. This raises a couple of questions:
>
&g
the release notes)
* JSONB and related features (such as indexing)
* ALTER SYSTEM SET
Lemme know if you need description text for any of the above.
--
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 05/05/2014 10:25 AM, Andres Freund wrote:
> On 2014-05-05 10:16:27 -0700, Josh Berkus wrote:
>> On 05/03/2014 01:07 AM, Andres Freund wrote:
>>> On 2014-05-02 18:57:08 -0700, Josh Berkus wrote:
>>>> Just got a report of a replication issue with 9.2.8
h does the same. So I think the above questions
are worth answering in general. And we're planning to implement
automated file management for cstore_fdw fairly soon, so we want to make
it consistent with whatever we're doing in Postgres 9.5.
--
Josh Berkus
PostgreSQL Experts Inc.
On 05/03/2014 01:07 AM, Andres Freund wrote:
> On 2014-05-02 18:57:08 -0700, Josh Berkus wrote:
>> Just got a report of a replication issue with 9.2.8 from a community member:
>>
>> Here's the sequence:
>>
>> 1) A --> B (sync rep)
>>
>> 2) Shut
()),
> but the other ones really should be covered or desupported.
>
> Greetings,
>
> Andres Freund
>
--
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
lication mode, especially in sync rep mode; that
should have failed. Any thoughts on why it didn't?
I'm trying to produce a test case ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
hooks. We really need some contrib/ modules which take
advantage of these.
--
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 05/01/2014 11:19 PM, Ian Barwick wrote:
>
> Here is an initial version of an auditing extension for Postgres to
> generate log output suitable for compiling a comprehensive audit trail
> of database operations.
Cool! Looking forward to seeing it around the 9.5 cycle.
--
ed a central contention point (the
> btree root).
Yes. And being smaller isn't insignificant; think of billion-row tables
with fairly random access over the whole table. Also, *theoretically*,
a hash index could avoid the rebalancing issues which cause our btree
indexes to become bloated an
601 - 700 of 5051 matches
Mail list logo
