s how this community works.
Alternately, you can just work on the individual FDW features, which
*everyone* thinks are a good idea, and when most of them are done,
FDW-based scaleout will be such an obvious solution that nobody will
argue with it.
--
--
Josh Berkus
Red Hat OSAS
(any opinio
tive Projects
> http://collabprojects.linuxfoundation.org/
> * Which software/services in what category should we address preferentially?
> What software would many users desire to be interoperable when migrating
> from commercial databases?
> What is the effective way to absorb u
All,
http://blogs.microsoft.com/?p=67248
Once SQL Server is available on Linux, we're going to see more people
using it as an alternative to PostgreSQL. Especially since they're
picking up a lot of our better features, like R support.
--
--
Josh Berkus
Red Hat OSAS
(any opinions
On 03/07/2016 01:43 PM, Josh berkus wrote:
All,
http://blogs.microsoft.com/?p=67248
Once SQL Server is available on Linux, we're going to see more people
using it as an alternative to PostgreSQL. Especially since they're
picking up a lot of our better features, like R support.
S
original copyright notice. You can *add* whatever you want.
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
commenting here)
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
abalance FROM account WHERE id = :aid
\into :lid, :lbal
\vlog balancelog :lid, :lbal
It would create a file called:
2247.balancelog.varlog
and/or append a line:
2016-03-30 21:37:33.899, 511, 2150
This would allow CSV logging of all sorts of user custom information,
including de-facto response
at doesn't use the C
> locale. Maybe it's not worth worrying about.
I think that's a great idea.
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
http://www.zdnet.com/article/microsoft-and-canonical-partner-to-bring-ubuntu-to-windows-10/
... could be good news for us ...
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On 03/30/2016 02:47 PM, Josh berkus wrote:
> On 03/29/2016 07:43 PM, Peter Geoghegan wrote:
>> Do you think it would be okay if the SQL query to detect potentially
>> affected indexes only considered the leading attribute? Since that's
>> the only attribute that coul
members
are unhappy with the amount of list traffic devoted to the subject of
CoCs. As such, if you have comments on the plan above, please email the
core team instead of replying on-list, or wait for the committee and
address comments to them.
--Josh Berkus
PostgreSQL Core Team
--
Sent via p
y.
We're not going to use CE for the new partitioning long-term, are we?
This is just the first version, right?
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
(like
timeline) which is exposed ONLY in pg_controldata. That leaves no
reasonable way to expose this information in an API.
(and yes, we have a bigger issue with stuff which is only in pg_log, but
one thing at a time)
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)
--
Sent via
e it seems good enough.
What I like about this is that if I want to expose it to a
non-superuser, I can just do a GRANT instead of needing to write a
security definer view.
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
ke to mentor this project with Oleg.
+1
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
significant (+144MB for the base 3 WAL segments). I'm not sure this is
a real problem which users will notice (in today's scales, 144MB ain't
much), but if it turns out to be, it would be nice to have a way to
switch it back *just for them* without recompiling.
--
--
Josh Berkus
R
or when they wanted quorum. So the sensible default
would be:
"k (n1, n2, n3)" == "any k (n1, n2, n3)"
... however, that will break backwards compatibility. Thoughts?
My $0.02 is that we break backwards compat somehow and document the heck
out of it.
--
--
Josh Berkus
R
both development and adoption.
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
option in 10?
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/12/2016 05:00 PM, Robert Haas wrote:
> On Sun, Oct 9, 2016 at 9:51 PM, Josh Berkus wrote:
>> Given that hot_standby_feedback is pretty bulletproof now, and a lot of
>> the work in reducing replay conflicts, I think the utility of
>> vacuum_defer_cleanup_age is at an en
On 10/18/2016 01:28 PM, Robert Haas wrote:
> On Tue, Oct 18, 2016 at 4:18 PM, Josh Berkus wrote:
>> On 10/12/2016 05:00 PM, Robert Haas wrote:
>>> On Sun, Oct 9, 2016 at 9:51 PM, Josh Berkus wrote:
>>>> Given that hot_standby_feedback is pretty bulletproof now,
On 10/18/2016 01:37 PM, Andres Freund wrote:
> Hi,
>
> On 2016-10-09 21:51:07 -0700, Josh Berkus wrote:
>> Given that hot_standby_feedback is pretty bulletproof now, and a lot of
>> the work in reducing replay conflicts, I think the utility of
>> vacuum_defer_cleanup_
t; standby to the master, while vacuum_defer_cleanup_age behaves like
> old_snapshot_threshold in that it causes cancel for long-running
> queries.
See Andres' response on this thread. He's already covered why the
setting is still useful, but why we might want to remove it anyway.
--
load use-case, it makes far more sense to do batch loads interspersed
with ANALYZEs and VACUUMS of loaded/updated tables.
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/20/2016 06:34 AM, Joshua D. Drake wrote:
> On 10/19/2016 07:22 PM, Josh Berkus wrote:
>> On 10/19/2016 06:27 PM, Joshua D. Drake wrote:
>>> Hello,
>>>
>>> After all these years, we are still regularly running into people who
>>> say, "perfor
ven stronger reason
to *lower* autovacuum_max_freeze_age. Since there's little duplicate
work in a freeze scan, a lot of users will find that frequent freezing
benefits them a lot ... especially if they can take advantage of
index-only scans.
--
--
Josh Berkus
Red Hat OSAS
(any opinions are
the last three weeks doesn't mean this effort is
> dead; I would like very much to see it move forward.
Has this gone anywhere? Given that we're in "break all the things" mode
for PostgreSQL 10, it would be the ideal time to consolidate
recovery.conf with pg.conf.
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/21/2016 10:29 AM, Robert Haas wrote:
> On Fri, Oct 21, 2016 at 1:17 PM, Josh Berkus wrote:
>> Particularly, with 9.6's freeze map, point (2) is even stronger reason
>> to *lower* autovacuum_max_freeze_age. Since there's little duplicate
>> work in a freeze
rays.
Huh? Sure it is. Ships in PostgreSQL-core.
I mean, I'm not particularly in favor of using JSON for this (arrays
seem OK), but that seems like an invalid reason not to.
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
riting the trigger file doesn't show up as a problem
since, in a containerized environment, they can't. It's either written
by postgres itself, or by management software which runs as the postgres
user.
--
Josh Berkus
Containers & Databases Oh My!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
w version coming up.
>
> Do you have an idea when the new version will be available?
Please? Having yet another PostgreSQL release go by without fixing
recovery.conf would make me very sad.
--
Josh Berkus
Containers & Databases Oh My!
--
Sent via pgsql-hackers mailing list (pgsql
curly braces etc.
> But that's my own preference maybe.
>
> (Btw. does "run off" mean like or avoid? At least my dictionaries tend
> to the latter.)
Yes, but automated tools can easily convert between JSON and
newline-delimited YAML and back.
--
Josh Berkus
Cont
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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/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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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?
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
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
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
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
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
. 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
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
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
?
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
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:
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
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
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
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: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
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
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
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
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
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
eciated work.
>
And only a week over schedule. Good work.
--
Josh Berkus
Containers & Databases Oh My!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s to detect that the "user" accessing the
target database is actually a logical replication subscription, and give
the DBA a better error message (e.g. "database 'bookdata' still has open
subscrptions")?
--
Josh Berkus
Containers & Databases Oh My!
--
Sent via
the setup is going to be sorry regardless,
keeping backwards compatibility is acceptable.
--
Josh Berkus
Containers & Databases Oh My!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ot any of the other strings.
This is because the # in <#> is an exact match.
Seems like we could really use a way for users to indicate that they
want a range of word gaps. Like, in the example above, users could
search on:
'fix <1:3> error'
... which would search for any
svector | json_to_tsvector | 114 | s
to_tsvector | jsonb_to_tsvector_byid | 3734 3802 | s
to_tsvector | json_to_tsvector_byid | 3734 114| s
... can we fix that?
--
Josh Berkus
Containers & Databases Oh My!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter and Petr:
On 06/07/2017 05:24 PM, Peter Eisentraut wrote:
> On 6/7/17 01:01, Josh Berkus wrote:
>> * Having defaults on the various _workers all devolve from max_workers
>> is also great.
>
> I'm not aware of anything like that happening.
>
>>
On 06/07/2017 06:25 PM, Petr Jelinek wrote:
> On 08/06/17 03:19, Josh Berkus wrote:
>>
>> Peter and Petr:
>>
>> On 06/07/2017 05:24 PM, Peter Eisentraut wrote:
>>> On 6/7/17 01:01, Josh Berkus wrote:
>>>> * Having defaults on the various _workers
On 06/07/2017 07:01 PM, Petr Jelinek wrote:
> On 08/06/17 03:50, Josh Berkus wrote:
>> On 06/07/2017 06:25 PM, Petr Jelinek wrote:
>>> On 08/06/17 03:19, Josh Berkus wrote:
>>>>
>>>> Peter and Petr:
>>>>
>>>> On 06/07/2017 05:24 PM
On 06/07/2017 06:37 PM, Peter Eisentraut wrote:
> On 6/7/17 21:19, Josh Berkus wrote:
>> The user's first thought is going to be a network issue, or a bug, or
>> some other problem, not a missing PK. Yeah, they can find that
>> information in the logs, but only if they t
_to_tsvector_byid | 3734 3802 | s
to_tsvector | json_to_tsvector_byid | 3734 114| s
Both of the _byid functions should be marked immutable, no? Otherwise
how can users use the new functions for indexing?
--
Josh Berkus
Containers & Databases Oh My!
--
Sent via pgsql-hackers mailing
On 06/09/2017 07:54 PM, Greg Stark wrote:
> On 7 June 2017 at 01:01, Josh Berkus wrote:
>> P3: apparently jsonb_to_tsvector with lang parameter isn't immutable?
>> This means that it can't be used for indexing:
>>
>> libdata=# create index bookdata_fts on
en around Postgres 16 eliminate it. I posit that that's better
than changing the meaning of the old syntax out from under people.
--
Josh Berkus
Containers & Databases Oh My!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Pavel, All:
Just to be clear, the idea of a global temp table is that the table def
is available to all users, but the data is private to each session?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
1 - 100 of 4826 matches
Mail list logo
