e option.
2. parallel continues to make progress
My argument is that even if we get nothing else, the above two are
enough to "bump" it to 10.0. And if we can have argreement on that now,
then we can avoid a month-long argument about version numbers next year.
--
--
Josh Berkus
Red Hat OSA
;>> Any others?
>>>>>
>>>> Incremental materialized views?
>>>
>>> I don't know. Is that something academics would research?
>>
>> Absolutely! There are plenty of papers on how to keep materialized views
>> up-to-date.
>
> Oh, OK
!
--
--
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 05/06/2016 02:12 PM, Andres Freund wrote:
> On 2016-05-06 14:10:04 -0700, Josh berkus wrote:
>> On 05/06/2016 02:08 PM, Andres Freund wrote:
>>
>>> It bothers me more than it probably should: Nobdy tests, reviews,
>>> whatever a complex patch wit
na happen *every* time.
https://en.wikipedia.org/wiki/Law_of_triviality
--
--
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
e word "FORCE" that bothers me. When you
>> use FORCE there is an assumption that no matter what, it plows through
>> (think rm -f). So if we don't use FROZEN, that's cool but FORCE doesn't work
>> either.
>
> SCANALL?
>
VACUUM THEWHOLEDAMNTHING
--
--
Josh
> 3(tie). 848ef42 Add the "snapshot too old" feature
>
> Congratulations Kevin, Tom, me, and me!
>
> I feel like I went to the Olympics and won both the gold *and* silver
> medals in the same event. Beat that!
>
Maybe we *should* call this 10.0. That way people
r the poll
> closes.
We should send the owner of the scariest patch something as a prize.
Maybe a plastic skeleton or something ...
--
--
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
po or whatever with your
roadmap and invite other full-time PostgreSQL contributors to add their
pieces.
--
--
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
format one day". But nobody is working on anything which will and
justifies it.
--
--
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 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 could
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
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
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 times.
--
--
Josh Berkus
Red Hat OSAS
(any
)
--
--
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
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
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.
Sorry
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 are my own
.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 user requests for this? Is it
> enou
u 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 opinions are my own)
--
Sent via pgsql-hackers ma
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
system handle 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-h
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 pgsql
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.postgresql.org
ing the options-inside-parentheses format, the way
EXPLAIN does nowadays, something like:
NOTIFY (DEDUPLICATE FALSE, MODE IMMEDIATE) mychannel;
Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
frequently or assertively.
In the meantime, our policy remains: if you have experienced harassment
or feel that you are being treated unfairly by other project members,
email the Core Team and we will investigate your complaint and take
appropriate action.
Also, we want to thank Josh Drake for raisi
t of people's imperfections.
Yeah, we could also get rid of this conversation:
"Here's a patch for X, which is on the TODO list"
"Oh, we've obsolesced that, that was added to the TODO before we had Y"
... by auto-closing TODO items at a certain age.
--
Josh Berkus
Red Hat O
xt on one row is kinda painful, and not at all useful.
--
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 separating the rows. This matters a lot if
> only a few of the column values are very wide: everywhere else, there's
> gonna be lots of whitespace.
What pager lets me scroll right infinitely? Because I wanna install that.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
Folks,
We are going to try to get Beta2 wrapped on Monday for a release next
week. So if you're currently working on a 9.5 Open Item, getting it
checked in tommorrow or this weekend would be great.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing
e a transaction is normally very
> fast and in a corner case it becomes extremely slow and disruptive to
> the rest of the system. In those cases, having a timeout for it is
> valuable.
I could see a use for both, having written scripts which do both.
--
Josh Berkus
PostgreSQL Expert
ial useful outcome. How about we terminate it now?
--
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
users avoid the "mistake" I just made.
>
> Frankly, that behavior strikes me as a good idea. There is no situation,
> IMV, where it's sane to try to put a symlink there.
So, just a doc patch then?
Since we have both include files and config_dir, I really don't
understand why anyone symli
>> viewing Citus Data source code has the same problems as Greenplum.
>
> Actually, it might only be their closed source software that contains
> patents, i.e. not pg_shard. I will check and report back when I can
> unless someone else reports here first.
I will ask Citus Data for an
n complexity.
+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
ike refactoring --- in particular, we'd
> usually not consider refactoring as fit material for back-patching.
>
> "Refactoring" seems rather a narrow definition of what might show up
> in such a category, btw. Maybe "Code Beautification" would be a
> suitable title?
o the end of the list?
>
> The initial commit grouped them logically, and it went downhill from
> there. :)
Yeah, we're overdue for another overhaul of GUC ordering.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
veral URLs should be easier to understand, easier to
> test, easier to code, and easier to keep from blowing up badly.
>
>
> Setting aside all other concerns, have a +1 from me on that too.
I'm good with this. +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
act?
> Well, multixacts are a lot larger than the other SLRUs, I think that
> makes some sort of difference.
And by "a lot larger" we're talking like 50X to 100X. I regularly see
pg_multixact directories larger than 1GB.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
tate of the globals dict
as a feature? That is, make use of the fact that you can store
session-persistent data in 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
n'.
I think having two different syntaxes is a bad idea. I'd rather have a
wholly proprietary configuration markup than deal with two alternate ones.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
more prompt.
--
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 the queue.
I have yet to see a bug tracker which does this particular task well, so
please don't emulate existing art.
--
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
On 10/07/2015 10:25 AM, Alvaro Herrera wrote:
> Hmm, I guess we could have the bug form add
> To: n...@bugs.postgresql.org
> CC: pgsql-b...@postgresql.org
> as headers, which should work for most people (since we reply-all), Josh
> Berkus being the exception.
Well, this will jus
On 10/07/2015 11:05 AM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> On 10/07/2015 10:25 AM, Alvaro Herrera wrote:
>>> Hmm, I guess we could have the bug form add
>>> To: n...@bugs.postgresql.org
>>> CC: pgsql-b...@postgresql.org
>>> as headers, whic
On 10/06/2015 12:03 PM, Bruce Momjian wrote:
> On Tue, Oct 6, 2015 at 03:33:20PM -0300, Alvaro Herrera wrote:
>> Joshua D. Drake wrote:
>>> On 10/06/2015 10:57 AM, Josh Berkus wrote:
>>>> On 10/06/2015 10:17 AM, Bruce Momjian wrote:
>>
>>>> Speak
onvert to "stale" status.
Until we build up a team of volunteers for bug triage, we might have to
do that.
Speaking of which ... this project is rich in skilled users who are
involved in the community but don't code. Bug triage is exactly the
kind of thing very part-time community suppor
rity an afterthought, which makes my teeth itch, but I think layers
> of security would make it much less likely to be actually adopted.
I think there needs to be some kind of administrative access which
allows, for example, an issue to be closed so that it can't be reopened.
Anyway, I'm not
luding it in the releases, speak up ...
Wait, we're backpatching 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
specific
error message the user is getting, which is a minority of the time.
So in addition to what Haas mentions, I think we want to be able to link
the release notes to the original issues for our hypothetical bug tracker.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via
d,
>> for example, log messages, function names, variables, etc.
>
> I'd be inclined to keep calling it the visibility map (vm) even if it
> also contains freeze information.
>
-1 to rename. Visibility Map is a perfectly good name.
--
Josh Berkus
PostgreSQL Experts Inc.
htt
effort. In this entire massive thread, so far
> only Josh has come up with what I'd consider to be actionable problem
> cases.
I don't see any way to make small tweaks to the existing process which
would fix any of these problems. I think if that were possible, we'd
already have done it.
Github Issues. If it's more than that, you're going
to have to explain.
--
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/2015 03:27 PM, Tom Lane wrote:
> Josh Berkus <j...@agliodbs.com> writes:
>> On 09/30/2015 03:10 PM, Tom Lane wrote:
>>> I'd be feeling a lot more positive about this whole thread if any people
>>> had stepped up and said "yes, *I* will put in a l
this thread is a waste of time, just as the several similar ones
> before it have been.
Hmmm? Frost volunteered to stand up debbugs.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
p:
rm -rf /pgdata/*
cp -p -r /pgdata2/* /pgdata/
... as expected, this did NOT cause postgres to shut down.
--
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.post
Hi. I have a need to pipe the output from pg_basebackup for a
multi-tablespace cluster into another program without spooling to
disk. Seeing as the current -F tar output format can't do that, I've
made an attempt at implementing that myself.
As a side effect I've refactored the some of the
On 09/29/2015 12:47 PM, Tom Lane wrote:
> Josh Berkus <j...@agliodbs.com> writes:
>> In general, having the postmaster survive deletion of PGDATA is
>> suboptimal. In rare cases of having it survive installation of a new
>> PGDATA (via PITR restore, for example)
all of the above requires a bug *tracker*, that is, a tool
which tracks the bug activity which was happening anyway, just makes it
more visible. Rather than an Issue Resolution System, which would be
intended to remake our workflow.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
s
suboptimal. In rare cases of having it survive installation of a new
PGDATA (via PITR restore, for example), I've even seen the zombie
postmaster corrupt the data files.
So if you want this change to be useful beyond the buildfarm, it should
check every few minutes, and you'd SIGQUIT.
--
Josh Berku
ld die, rather than a small list that cause us
> not to. But as long as we're reasonably confident that we're seeing an
> error that means somebody deleted pg_control, I think abandoning ship
> is just fine.
Give me source with the change, and I'll put it on a cheap, low-bandwith
AWS in
doesn't have a bug and our stuff is
> blowing up, then we have a bug and should fix it. I suppose there
> could be some grey area but hopefully not too much.
Or it's PILBChAK. I know Sun-CC used to warn that -O3 was unsuitable for
most programs because it could change behavior.
--
Josh
y would we bother?
The infra team seems to be good with debbugs, and several committers
seem to like it, why not go with 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
he only time this info is required is for people that provide a Support
> service based upon PostgreSQL, yet are not themselves sufficiently
> involved to know what bugs have been reported and are as yet unfixed. I
> expect such people are extremely interested in getting other people to
a attributes as well, yes? I have a
destruction test case for correlated column stats, so I'd like to test
your patch on it.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
; https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=util-linux;dist=unstable
>
> A specific bug:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786804
I adore "Toggle useless messages" as a feature. ;-)
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via
ce, we won't go breaking everyone's links when we change the domain
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
age says "Fixes bug #1234"
> and the state automatically goes to FIXED.
I don't know debbugs, but I know that it would be possible to program RT
to do all of the above, except add the item to the commitfest.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgs
le.
>
Yes. Please just build an external extension and submit it to PGXN.
Thanks!
--
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
trivial code fixes might be a side benefit,
but isn't a good enough reason to have one.
Obviously, everything said about "who's going to maintain this" is
completely valid.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hack
ould be willing to
help here.
--
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 Jira to be superior to OSS BT systems, and inferior
in several ways (like that you can't have more than one person assigned
to a bug). And email integration for Jira is nonexistant.
When we discussed this 8 years ago, Debian said debbugs wasn't ready for
anyone else to use. Has that changed?
--
Jo
ltixact
truncation at all?
--
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
My solution will depend on patroni's included HTTP access, though, so
I'm not sure it will work for you. Anyway, this isn't a topic for
pgsql-hackers mailing list, so reply offlist if you want to discuss further.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hac
m version: 0
--
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
a feature, too, is nice.
(* there are actually other ways to come close to simultaneity, but they
are much more complicated)
--
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
by toplevel make install; I'm not suggesting that the
>>> extension is installed automatically. For that, you still need a
>>> superuser to run CREATE EXTENSION.
>>>
>>
>> +! for this
>
> OK, what does "+!" mean? (I know it is probably a shif
On 09/01/2015 04:14 PM, Petr Jelinek wrote:
> On 2015-09-02 00:09, Josh Berkus wrote:
>> On 09/01/2015 02:29 PM, Tomas Vondra wrote:
>>> So while you may be right in single-DC deployments, with multi-DC
>>> deployments the situation is quite different - not only tha
On 09/02/2015 11:41 AM, Robert Haas wrote:
> On Wed, Sep 2, 2015 at 1:57 PM, Josh Berkus <j...@agliodbs.com> wrote:
>> Even if it's only on paper, any new sharding design needs to address
>> these questions:
>>
>> 1. How do we ensure no/minimal data is lost i
On 09/02/2015 12:30 PM, Robert Haas wrote:
> On Wed, Sep 2, 2015 at 3:03 PM, Josh Berkus <j...@agliodbs.com> wrote:
>>> 4. Therefore, I think that we should instead use logical replication,
>>> which might be either synchronous or asynchronous. When you modi
But we actually say this in the docs:
My experience with performance tuning is that values above 3 have no
real effect on how queries are executed.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
or the pg_controldata output it processes the
> pg_control file directly, and for pg_config it relies on compile-time
> CPPFLAGS.
>
> I think trying to duplicate the exact strings isn't too nice an
> interface.
Well, for pg_controldata, no, but what else would you do for pg_config?
--
Josh B
ee a strong place for binary replication and BDR for
multi-region redundancy; you really don't want that to be part of the
sharding system if you're aiming for write scalability.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
On 09/01/2015 02:39 AM, Bruce Momjian wrote:
> On Mon, Aug 31, 2015 at 01:16:21PM -0700, Josh Berkus wrote:
>> I'm also going to pontificate that, for a future solution, we should not
>> focus on write *IO*, but rather on CPU and RAM. The reason for this
>> thinking is
On 09/01/2015 10:17 AM, Robert Haas wrote:
> On Tue, Sep 1, 2015 at 1:06 PM, Josh Berkus <j...@agliodbs.com> wrote:
>> Any sharding solution worth bothering with will solve some or all of the
>> above by extending our ability to process requests across multiple
>> node
On 09/01/2015 02:29 PM, Tomas Vondra wrote:
> Hi,
>
> On 09/01/2015 09:19 PM, Josh Berkus wrote:
>> Other way around, that is, having replication standbys as the only
>> method of redundancy requires either high data loss or high latency
>> for all writes.
>
> I
illed user; that is, requiring a special
C sharding function for this seems fine to me.
--
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/31/2015 02:47 PM, Robert Haas wrote:
> On Mon, Aug 31, 2015 at 4:16 PM, Josh Berkus <j...@agliodbs.com> wrote:
>> First, let me put out there that I think the horizontal scaling project
>> which has buy-in from the community and we're working on is infinitely
>>
/wiki/PostgreSQL_9.5_Open_Items
When that list gets down to a handful of non-critical items, we'll be in
beta. Help wanted.
--
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
On 08/21/2015 08:34 PM, Jim Nasby wrote:
On 8/18/15 12:31 PM, Josh Berkus wrote:
Also this would be useful for range
partitions:
CREATE PARTITION ON parent_table USING ( start_value );
... where start_value is the start range of the new partition. Again,
easier for users to get correct
be in the first cut even if they require an
access exclusive lock.
Cheers,
David.
I don't see a way for them to *ever* not require an access exclusive lock.
We could eventually implement:
DETACH PARTITION CONCURRENTLY
... but that's the only way I can see around it.
--
Josh Berkus
On 08/20/2015 12:24 PM, Jim Nasby wrote:
On 8/17/15 4:25 PM, Josh Berkus wrote:
On 08/17/2015 02:18 PM, Jim Nasby wrote:
On 8/17/15 3:33 PM, Josh Berkus wrote:
Again, how do we handle missing keys? Just return NULL? or
ERROR? I'd
prefer the former, but there will be arguments the other
ON (columns) INCREMENT BY (INTERVAL '1 month' )
START WITH value;
Oh, I like that syntax!
How would it work if there were multiple columns? Maybe we don't want
to allow that for this form?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql
many
users deliberately use CTEs as an optimization barrier in order to force
the planner. Given that, we need some kind of option to force the old
behavior; either SQL syntax or a GUC option. Otherwise this will cause
a bunch of backwards-compatibility breakage.
Ideas?
--
Josh Berkus
PostgreSQL
On 08/19/2015 01:32 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
On 08/18/2015 04:40 PM, Qingqing Zhou wrote:
Attached please find the WIP patch and also the ANALYZE results.
Notes: the patch may not directly apply to head as some network issue
here so my Linux box can't talk
On 08/19/2015 01:18 PM, Thom Brown wrote:
On 19 August 2015 at 21:10, Josh Berkus j...@agliodbs.com
mailto:j...@agliodbs.com wrote:
On 08/19/2015 04:59 AM, Simon Riggs wrote:
I like the idea of a regular partitioning step because it is how you
design such tables - lets use
that partition.
--
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
EXPLAIN [ANALYZE]
Would be tricky. We don't currently have any way to wrap an EXPLAIN in
any larger statement, do we? Would be very useful for automated query
analysis, though.
SHOW
Not very useful, easy to work around (pg_settings).
--
Josh Berkus
PostgreSQL Experts Inc.
http
On 08/17/2015 02:18 PM, Jim Nasby wrote:
On 8/17/15 3:33 PM, Josh Berkus wrote:
Again, how do we handle missing keys? Just return NULL? or ERROR? I'd
prefer the former, but there will be arguments the other way.
I've been wondering if we should add some kind of strict JSON. My big
of in this
implementation?
array/key ambiguity is going to be painful.
--
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
101 - 200 of 4970 matches
Mail list logo
