On Wed, Aug 27, 2014 at 5:16 AM, Fujii Masao wrote:
> On Wed, Aug 27, 2014 at 6:16 AM, Magnus Hagander wrote:
>> On Tue, Aug 26, 2014 at 10:46 PM, Andres Freund
>> wrote:
>>> On 2014-08-26 16:41:44 -0400, Peter Eisentraut wrote:
On 8/26/14 12:40 PM, Magnus Hagander wrote:
> I think th
On Wed, Aug 27, 2014 at 3:41 PM, Andres Freund wrote:
> Can you add it to the next CF? I'll try to look earlier, but can't
> promise anything.
>
> I very much would like this to get committed in some form or another.
Added it here to keep track of it:
https://commitfest.postgresql.org/action/patch
On 08/27/2014 09:40 AM, Heikki Linnakangas wrote:
On 08/27/2014 08:23 AM, Jeff Davis wrote:
On Tue, 2014-08-26 at 13:45 +0300, Heikki Linnakangas wrote:
Yeah. This patch in the current state is likely much much slower than
unpatched master, except in extreme cases where you have thousands of
co
On 2014-08-27 11:00:56 +0900, Michael Paquier wrote:
> On Tue, Jan 21, 2014 at 10:12 PM, Michael Paquier
> wrote:
> > I have realigned this patch with latest head (d2458e3)... In case
> > someone is interested at some point...
> Attached is a patch for REINDEX CONCURRENTLY rebased on HEAD
> (d7938
On 08/27/2014 08:23 AM, Jeff Davis wrote:
On Tue, 2014-08-26 at 13:45 +0300, Heikki Linnakangas wrote:
Yeah. This patch in the current state is likely much much slower than
unpatched master, except in extreme cases where you have thousands of
connections and short transactions so that without th
On 2014-08-26 20:44:32 -0500, Jim Nasby wrote:
> These results look very encouraging, especially thinking about the
> cache impact.
Yep. I've seen PrivateRefCount array accesses prominently in the source
of cache misses in big servers.
> It occurs to me that it'd also be nice to have some
> stats
On 2014-08-26 22:04:03 -0400, Robert Haas wrote:
> On Tue, Aug 26, 2014 at 7:52 PM, Andres Freund wrote:
> > Here's the next version of this patch.
>
> + *much never requried. So we keep a small array of reference counts
>
> Typo. But I think you could just drop the whole sentence about
On 2014-08-26 22:19:47 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The biggest concern previously were some benchmarks. I'm not entirely
> > sure where to get a good testcase for this that's not completely
> > artificial - most simpler testcases don't pin many buffers.
>
> FWIW, I think th
On 23 August 2014 11:22, Michael Paquier Wrote:
> >> 2. Logic of deciding the highest priority one seems to be in-correct.
> >> Assume, s_s_num = 3, s_s_names = 3,4,2,1
> >> standby nodes are in order as: 1,2,3,4,5,6,7
> >>
> >> As per the logic in patch, node 4 with priori
On Tue, 2014-08-26 at 22:13 -0700, Jeff Davis wrote:
> Attached a patch implementing the same idea though: only use the
> multibyte path if *both* the escape char and the current character from
> the pattern are multibyte.
Forgot to mention: with this patch, the test completes in about 720ms,
so j
On 27/08/14 10:27, Alvaro Herrera wrote:
Alvaro Herrera wrote:
So my proposal is a bit more complicated. First we introduce the notion
of a single number, to enable sorting and computations: the "delay
equivalent", which is the cost_limit divided by cost_delay.
Here's a patch that implements
On Tue, 2014-08-26 at 13:45 +0300, Heikki Linnakangas wrote:
> Yeah. This patch in the current state is likely much much slower than
> unpatched master, except in extreme cases where you have thousands of
> connections and short transactions so that without the patch, you spend
> most of the tim
On Mon, 2014-08-25 at 17:41 +0300, Heikki Linnakangas wrote:
> Actually, that gets optimized to a constant in the planner:
Oops, thank you (and Tom).
> your patch seems to be about 2x-3x as slow as unpatched master. So this
> needs some optimization. A couple of ideas:
I didn't see anywhere nea
On Wed, Aug 27, 2014 at 12:31 PM, Fujii Masao wrote:
> On Wed, Aug 27, 2014 at 10:34 AM, Michael Paquier
> wrote:
> I think that it's better to add an include guard like
>
> #ifndef RECEIVELOG_H
> #define RECEIVELOG_H
> ...
> #endif
Oh indeed, that was missing as well! Please see attached.
--
Mi
On Tue, Aug 26, 2014 at 11:55 PM, Greg Stark wrote:
> Interesting analysis.
>
> I suppose the equivalent of hint bits would be to actually write the
> CSN of the transaction into the record when the hint bit is set.
>
> I don't immediately see how to make that practical. One thought would
> be to
On Wed, Aug 27, 2014 at 12:48 PM, Tom Lane wrote:
> I wrote:
>> Stephen Frost writes:
>>> Consider an audit system where which columns end up in the audit log are
>>> controlled by issuing ALTER TABLE .. ALTER COLUMN type statements.
>
>> I'd like to consider such a thing, but it seems like utter
On Wed, Aug 27, 2014 at 1:10 PM, Michael Paquier
wrote:
> On Tue, Aug 26, 2014 at 8:10 AM, Michael Paquier
> wrote:
>> Well, I like the patch series for what it counts as long as you can
>> submit it as such. That's far easier to test and certainly helps in
>> spotting issues when kicking differe
On Tue, Aug 26, 2014 at 8:10 AM, Michael Paquier
wrote:
> Well, I like the patch series for what it counts as long as you can
> submit it as such. That's far easier to test and certainly helps in
> spotting issues when kicking different code paths.
So, for patch 2, which is a cosmetic change for
It won't be faster by any means, but it should definitely be incorporated
if any format changes are made (like Tom already suggested).
I think it's important we gather at least 2 more things before making any
calls:
* Josh tests w/ cache aware patch, which should confirm cache aware is
indeed pref
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wrote:
> > Stephen Frost writes:
> >> Consider an audit system where which columns end up in the audit log are
> >> controlled by issuing ALTER TABLE .. ALTER COLUMN type statements.
>
> > I'd like to consider such a thing, but it seems like utter pie in
On Tue, Aug 26, 2014 at 12:53 PM, Fabien COELHO wrote:
>
> Given the small flow of updates, I do not think that there should be
reason to get that big a write contention between WAL & checkpoint.
>
> If tried with "full_page_write = off" for 500 seconds: same overall
behavior, 8.5% of transactions
Peter Geoghegan writes:
> I'm not surprised that it hasn't beaten HEAD. I haven't studied the
> problem in detail, but I don't think that the "cache awareness" of the
> new revision is necessarily a distinct advantage.
I doubt it's a significant advantage in the current state of the code;
I'm hap
On Tue, 2014-08-26 at 02:05 +0200, Andres Freund wrote:
> Currently running "make -j16 all check" in contrib/ results in a mess
> because
> all pg_regress invocations fight over the same port. Adding a simple
> .NOTPARALLEL: check-%-recurse
> into contrib/Makefile fixes that. Do we want that?
But
On Tue, Aug 26, 2014 at 8:41 PM, Arthur Silva wrote:
> The difference is small but I's definitely faster, which makes sense since
> cache line misses are probably slightly reduced.
> As in the previous runs, I ran the query a dozen times and took the average
> after excluding runs with a high devi
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Consider an audit system where which columns end up in the audit log are
> > controlled by issuing ALTER TABLE .. ALTER COLUMN type statements.
>
>
>
> I'd like to consider such a thing, but it seems like utter pie in the
> sky.
I wrote:
> Stephen Frost writes:
>> Consider an audit system where which columns end up in the audit log are
>> controlled by issuing ALTER TABLE .. ALTER COLUMN type statements.
> I'd like to consider such a thing, but it seems like utter pie in the
> sky.
On further thought: the existing postm
Tom, here's the results with github data (8 top level keys) only. Here's a
sample object https://gist.github.com/igrigorik/2017462
All-Lenghts + Cache-Aware EXTERNAL
Query 1: 516ms
Query 2: 350ms
The difference is small but I's definitely faster, which makes sense since
cache line misses are prob
Stephen Frost writes:
> Consider an audit system where which columns end up in the audit log are
> controlled by issuing ALTER TABLE .. ALTER COLUMN type statements.
I'd like to consider such a thing, but it seems like utter pie in the
sky. Do you really believe that elog() could know enough a
On Wed, Aug 27, 2014 at 10:34 AM, Michael Paquier
wrote:
> On Wed, Aug 27, 2014 at 6:10 AM, Magnus Hagander wrote:
>> On Tue, Aug 26, 2014 at 11:03 PM, Robert Haas wrote:
>>> Probably that's a good idea, but do we really need Author: tags? I
>>> know we have those in a few places, but certainly
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
>
> > The flip side is that there are absolutely production cases where what
> > we output is either too little or too much- being able to control that
> > and then have the (filtered) result in JSON would be more-or-less
>
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > The flip side is that there are absolutely production cases where what
> > we output is either too little or too much- being able to control that
> > and then have the (filtered) result in JSON would be more-or-less
> > exact
Stephen Frost wrote:
> The flip side is that there are absolutely production cases where what
> we output is either too little or too much- being able to control that
> and then have the (filtered) result in JSON would be more-or-less
> exactly what a client of ours is looking for.
My impression
On Wed, Aug 27, 2014 at 6:16 AM, Magnus Hagander wrote:
> On Tue, Aug 26, 2014 at 10:46 PM, Andres Freund
> wrote:
>> On 2014-08-26 16:41:44 -0400, Peter Eisentraut wrote:
>>> On 8/26/14 12:40 PM, Magnus Hagander wrote:
>>> > I think the first reason is gone now, and the risk/damage of the two
>
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I think the extra representational overhead is already a good reason to
>> say "no". There is not any production scenario I've ever heard of where
>> log output volume isn't a consideration.
> The flip side is that there are absol
On Thu, 2014-08-07 at 12:15 +0200, Marko Tiikkaja wrote:
> On 8/6/14 2:46 PM, I wrote:
> > Attached is a patch to add support for PGP signatures in encrypted
> > messages into pgcrypto.
>
> Here's v2 of the patch. I've changed the info-extracting code to not
> look for signatures beyond the data
On Tue, Aug 26, 2014 at 7:47 PM, Tom Lane wrote:
>> I think that it would be a good beginner's project to make pprint()
>> print JSON.
>
> There's something to be said for that (or, really, for any standardized
> widely-popular textual data format; but JSON is a perfectly reasonable
> candidate).
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier writes:
> > Now what about a json format logging with one json object per log entry?
>
> > A single json entry would need more space than a csv one as we need to
> > track the field names with their values. Also, there is always the
> > arg
Peter Geoghegan writes:
> I think that it would be a good beginner's project to make pprint()
> print JSON.
There's something to be said for that (or, really, for any standardized
widely-popular textual data format; but JSON is a perfectly reasonable
candidate).
> The existing infrastructure is
On Mon, 2014-08-25 at 09:33 +0200, Fabien COELHO wrote:
>
> Find a small documentation patch attached:
>
> - show the valid range for segment_timeout
> - remove one spurious empty line (compared to other descriptions)
Committed.
Please don't add patches to the commit fest well after it has
Michael Paquier writes:
> Now what about a json format logging with one json object per log entry?
> A single json entry would need more space than a csv one as we need to
> track the field names with their values. Also, there is always the
> argument that if an application needs json-format logs
On Thu, 2014-07-03 at 13:05 +0900, Kyotaro HORIGUCHI wrote:
> For the earlier than 9.4, no one seems to have considered
> seriously to use local_preload_library via ALTER statements so
> far. Only document fix would be enough for them.
I think local_preload_libraries never actually worked sensibly
Andres Freund writes:
> The biggest concern previously were some benchmarks. I'm not entirely
> sure where to get a good testcase for this that's not completely
> artificial - most simpler testcases don't pin many buffers.
FWIW, I think that's by design; we don't ever want to pin more than one
bu
(2014/08/27 11:06), Tom Lane wrote:
> Etsuro Fujita writes:
>> (2014/08/27 3:27), Tom Lane wrote:
>>> I looked this over, and TBH I'm rather disappointed. The patch adds
>>> 150 lines of dubiously-correct code in order to save ... uh, well,
>
>> Just for my study, could you tell me why you think
On Wed, Aug 27, 2014 at 8:27 AM, Alvaro Herrera
wrote:
> Alvaro Herrera wrote:
>
>> So my proposal is a bit more complicated. First we introduce the notion
>> of a single number, to enable sorting and computations: the "delay
>> equivalent", which is the cost_limit divided by cost_delay.
>
> Here
Etsuro Fujita writes:
> (2014/08/27 3:27), Tom Lane wrote:
>> I looked this over, and TBH I'm rather disappointed. The patch adds
>> 150 lines of dubiously-correct code in order to save ... uh, well,
> Just for my study, could you tell me why you think that the code is
> "dubiously-correct"?
It
On Tue, Aug 26, 2014 at 7:52 PM, Andres Freund wrote:
> Here's the next version of this patch.
+ *much never requried. So we keep a small array of reference counts
Typo. But I think you could just drop the whole sentence about how
things used to be, especially since it's recapitulated e
On Tue, Aug 26, 2014 at 5:12 PM, Andres Freund wrote:
> On 2014-08-26 12:44:43 +0900, Michael Paquier wrote:
> I always was of the opinion that a exclusive lock is still *MUCH* better
> than what we have today.
Well, if somebody has some interest in that, here is a rebased patch
with the approach
On Tue, Jan 21, 2014 at 10:12 PM, Michael Paquier
wrote:
> I have realigned this patch with latest head (d2458e3)... In case
> someone is interested at some point...
Attached is a patch for REINDEX CONCURRENTLY rebased on HEAD
(d7938a4), as some people are showing interest in it by reading recent
On Tue, Aug 26, 2014 at 6:45 PM, Michael Paquier
wrote:
> Thoughts?
I think that it would be a good beginner's project to make pprint()
print JSON. I spend enough time staring at its output that I've often
wished I could expand and collapse each part using my text editor's
folds feature. I guess
(2014/08/27 3:27), Tom Lane wrote:
> Etsuro Fujita writes:
>> [ attr_needed-v4.patch ]
>
> I looked this over, and TBH I'm rather disappointed. The patch adds
> 150 lines of dubiously-correct code in order to save ... uh, well,
Just for my study, could you tell me why you think that the code is
Hi all,
As mentioned here, we support multiple logging format:
http://www.postgresql.org/docs/devel/static/runtime-config-logging.html
Now what about a json format logging with one json object per log entry?
A single json entry would need more space than a csv one as we need to
track the field na
On 8/26/14, 6:52 PM, Andres Freund wrote:
On 2014-03-21 19:22:31 +0100, Andres Freund wrote:
>Hi,
>
>I've been annoyed at the amount of memory used by the backend local
>PrivateRefCount array for a couple of reasons:
>
>a) The performance impact of AtEOXact_Buffers() on Assert() enabled
>bui
On Wed, Aug 27, 2014 at 6:10 AM, Magnus Hagander wrote:
> On Tue, Aug 26, 2014 at 11:03 PM, Robert Haas wrote:
>> Probably that's a good idea, but do we really need Author: tags? I
>> know we have those in a few places, but certainly not everywhere, and
>> as time goes by they tend to be less ac
Hi Fabien,
On Tue, Aug 26, 2014 at 04:07 AM, Fabien COELHO wrote:
>
> Please find attached a new version which fixes these two points.
Indeed it does. Marking the patch ready for a committer.
Thanks,
♜
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
Hi,
On 2014-03-21 19:22:31 +0100, Andres Freund wrote:
> Hi,
>
> I've been annoyed at the amount of memory used by the backend local
> PrivateRefCount array for a couple of reasons:
>
> a) The performance impact of AtEOXact_Buffers() on Assert() enabled
>builds is really, really annoying.
>
Kevin Grittner wrote:
> I think this is approaching a committable state, although I think
> it should probably be broken down to four separate patches.
And here they are. This should net to the same set of changes as
the prior post, but the changes are logically separated. They are
labeled as
On 27/08/14 10:27, Alvaro Herrera wrote:
Alvaro Herrera wrote:
So my proposal is a bit more complicated. First we introduce the notion
of a single number, to enable sorting and computations: the "delay
equivalent", which is the cost_limit divided by cost_delay.
Here's a patch that implements
I wrote:
> I wish it were cache-friendly too, per the upthread tangent about having
> to fetch keys from all over the place within a large JSON object.
> ... and while I was typing that sentence, lightning struck. The existing
> arrangement of object subfields with keys and values interleaved is
Tom Lane-2 wrote
> Robert Haas <
> robertmhaas@
> > writes:
>> I liked David Johnston's even stronger suggestion upthread: make it an
>> error to specify a value requires rounding of any kind. In other
>> words, if the minimum granularity is 1 minute, you can specify that as
>> 60 seconds instea
Robert Haas writes:
> I liked David Johnston's even stronger suggestion upthread: make it an
> error to specify a value requires rounding of any kind. In other
> words, if the minimum granularity is 1 minute, you can specify that as
> 60 seconds instead, but if you write 59 seconds, we error out.
On Tue, Aug 26, 2014 at 10:46 PM, Andres Freund wrote:
> On 2014-08-26 16:41:44 -0400, Peter Eisentraut wrote:
>> On 8/26/14 12:40 PM, Magnus Hagander wrote:
>> > I think the first reason is gone now, and the risk/damage of the two
>> > connections is probably smaller than running out of WAL. -x i
On Tue, Aug 26, 2014 at 11:03 PM, Robert Haas wrote:
> On Sat, Aug 23, 2014 at 11:59 PM, Michael Paquier
> wrote:
>> As mentioned in $subject, the header files in src/bin/pg_basebackup do
>> not have a comment block at the top and do not have any copyright
>> text.
>> Any reason for that? Shouldn
On Sat, Aug 23, 2014 at 11:59 PM, Michael Paquier
wrote:
> As mentioned in $subject, the header files in src/bin/pg_basebackup do
> not have a comment block at the top and do not have any copyright
> text.
> Any reason for that? Shouldn't we have something for consistency with
> the other files li
On 8/26/14 4:22 PM, Andres Freund wrote:
> Is the whole topic actually practically relevant?
It's clearly not all that important, or otherwise we'd have heard about
before now.
I suppose someone could do something like
wal_receiver_status_interval = 10ms
and end up silently turning the whole th
On 8/23/14 6:39 PM, Greg Stark wrote:
> Or make it an error to specify a value that rounds to 0 but isn't 0.
That's what I would prefer.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-08-26 16:41:44 -0400, Peter Eisentraut wrote:
> On 8/26/14 12:40 PM, Magnus Hagander wrote:
> > I think the first reason is gone now, and the risk/damage of the two
> > connections is probably smaller than running out of WAL. -x is a good
> > default for smaller systems, but -X is a safer o
On 8/26/14 12:40 PM, Magnus Hagander wrote:
> I think the first reason is gone now, and the risk/damage of the two
> connections is probably smaller than running out of WAL. -x is a good
> default for smaller systems, but -X is a safer one for bigger ones. So
> I agree that changing the default mod
On 2014-08-26 16:16:32 -0400, Robert Haas wrote:
> On Sat, Aug 23, 2014 at 6:39 PM, Greg Stark wrote:
> > On Sat, Aug 23, 2014 at 9:38 PM, Tom Lane wrote:
> >>
> >> Ah. Okay, but then what's wrong with the original proposal of "use ceil()
> >> instead of floor()"? Basically I think the idea of
On Sat, Aug 23, 2014 at 6:39 PM, Greg Stark wrote:
> On Sat, Aug 23, 2014 at 9:38 PM, Tom Lane wrote:
>>
>> Ah. Okay, but then what's wrong with the original proposal of "use ceil()
>> instead of floor()"? Basically I think the idea of treating fractions
>> less than one differently from fracti
On Tue, 2014-08-26 at 21:00 +0100, Greg Stark wrote:
> Well fundamentally the reason the visibility information is with the
> user data is so that we don't need to do two i/os to access the data.
> The whole point of hint bits is to guarantee that after some amount of
> time you can read data direc
On Fri, Aug 22, 2014 at 9:48 PM, Kohei KaiGai wrote:
> One thing I was pointed out, it is the reason why I implemented
> DDL support, is that intermediation of c-language function also
> loads the extension module implicitly. It is an advantage, but
> not sure whether it shall be supported from th
On Tue, Aug 26, 2014 at 12:59 PM, Robert Haas wrote:
> I have committed a fix for that problem. Let me know if I missed
> something else.
Yes, that's all I meant.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
On Tue, Aug 26, 2014 at 8:32 PM, Jeff Davis wrote:
> We are mixing two kinds of data: user data and visibility information.
> Each is changed under different circumstances and has different
> characteristics, and I'm beginning to think they shouldn't be mixed at
> all.
>
> What if we just devised
On Fri, Aug 22, 2014 at 2:46 PM, Peter Geoghegan wrote:
> On Fri, Aug 22, 2014 at 7:19 AM, Robert Haas wrote:
>> Patch 0002 no longer applies; please rebase.
>
> I attach rebased patch.
>
> Note that there is currently a bug in the master branch:
>
> + if (len2 >= tss->buflen2)
> + {
> +
Hello Jeff,
The culprit I found is "bgwriter", which is basically doing nothing to
prevent the coming checkpoint IO storm, even though there would be ample
time to write the accumulating dirty pages so that checkpoint would find a
clean field and pass in a blink. Indeed, at the end of the 500 s
On 08/26/2014 12:27 PM, Andres Freund wrote:
> Anyway, that's just to say that I don't really agree that CPU overhead
> is a worthy price to pay for storage efficiency if the gains are small.
But in this case the gains aren't small; we're talking up to 60% smaller
storage.
Testing STORAGE EXTENDE
On Tue, 2014-08-26 at 12:39 +0300, Heikki Linnakangas wrote:
> I think this is enough for this commitfest - we have consensus on the
> design. For the next one, please address those open items, and resubmit.
Agreed, return with feedback.
I need to get the accounting patch in first, which needs t
On Thu, Aug 21, 2014 at 10:49 PM, Stephen Frost wrote:
> * Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
>> On 08/19/2014 04:27 AM, Brightwell, Adam wrote:
>> >This is a "proof-of-concept" patch for a new model around role attributes
>> >and fine grained permissions meant to alleviate the cu
On Tue, Aug 26, 2014 at 12:27 PM, Andres Freund wrote:
> Anyway, that's just to say that I don't really agree that CPU overhead
> is a worthy price to pay for storage efficiency if the gains are small.
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Tue, 2014-08-26 at 19:25 +0100, Greg Stark wrote:
> I don't immediately see how to make that practical. One thought would
> be to have a list of xids in the page header with their corresponding
> csn -- which starts to sound a lot like Oralce's "Interested
> Transaction List". But I don't see ho
On 2014-08-26 15:17:13 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-08-26 15:01:27 -0400, Tom Lane wrote:
> >> Yeah, exactly. Given current hardware trends, data compression is
> >> becoming more of a win not less as time goes on: CPU cycles are cheap
> >> even compared to main memo
On Tue, Aug 26, 2014 at 4:01 PM, Tom Lane wrote:
> Josh Berkus writes:
>> On 08/26/2014 11:40 AM, Tom Lane wrote:
>>> I was hoping you'd get some useful data from that, but so far it seems
>>> like a rehash of points made in the on-list thread :-(
>
>> Unfortunately even the outside commentors do
Andres Freund writes:
> On 2014-08-26 15:01:27 -0400, Tom Lane wrote:
>> Yeah, exactly. Given current hardware trends, data compression is
>> becoming more of a win not less as time goes on: CPU cycles are cheap
>> even compared to main memory access, let alone mass storage. So I'm
>> thinking w
On 26 August 2014 11:34, Josh Berkus wrote:
> On 08/26/2014 07:51 AM, Tom Lane wrote:
> > My feeling about it at this point is that the apparent speed gain from
> > using offsets is illusory: in practically all real-world cases where
> there
> > are enough keys or array elements for it to matter,
On 2014-08-26 15:01:27 -0400, Tom Lane wrote:
> Josh Berkus writes:
> > On 08/26/2014 11:40 AM, Tom Lane wrote:
> >> I was hoping you'd get some useful data from that, but so far it seems
> >> like a rehash of points made in the on-list thread :-(
>
> > Unfortunately even the outside commentors d
Josh Berkus writes:
> On 08/26/2014 11:40 AM, Tom Lane wrote:
>> I was hoping you'd get some useful data from that, but so far it seems
>> like a rehash of points made in the on-list thread :-(
> Unfortunately even the outside commentors don't seem to understand that
> storage size *is* related t
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 it seems
> like a rehash of poin
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 it seems
like a rehash of points made in the on-list thread :-(
On 08/26/2014 07:51 AM, Tom Lane wrote:
> My feeling about it at this point is that the apparent speed gain from
> using offsets is illusory: in practically all real-world cases where there
> are enough keys or array elements for it to matter, costs associated with
> compression (or rather failure
Etsuro Fujita writes:
> [ attr_needed-v4.patch ]
I looked this over, and TBH I'm rather disappointed. The patch adds
150 lines of dubiously-correct code in order to save ... uh, well,
actually it *adds* code, because the places that are supposedly getting
a benefit are changed like this:
*** 79
On Tue, Aug 26, 2014 at 11:45 AM, Heikki Linnakangas
wrote:
>> It appears that this patch weakens the idea of hint bits. Even if
>> HEAP_XMIN_COMMITTED is set, it still needs to find out if it's in the
>> snapshot.
>>
>> That's fast if the xid is less than snap->xmin, but otherwise it needs
>> to
On Tue, 2014-08-26 at 13:45 +0300, Heikki Linnakangas wrote:
> My current thinking is that access to the csnlog will need to be made
> faster. Currently, it's just another SLRU, but I'm sure we can do better
> than that. Or add a backend-private cache on top of it; that might
> already alleviate
On Tue, Aug 26, 2014 at 6:51 PM, Andres Freund wrote:
> On 2014-08-26 18:40:27 +0200, Magnus Hagander wrote:
>> On Mon, Aug 25, 2014 at 1:35 PM, Andres Freund
>> wrote:
>> > Hi,
>> >
>> > currently pg_basebackup uses fetch mode when only -x is specified -
>> > which imo isn't a very good thing t
On 2014-08-26 18:40:27 +0200, Magnus Hagander wrote:
> On Mon, Aug 25, 2014 at 1:35 PM, Andres Freund wrote:
> > Hi,
> >
> > currently pg_basebackup uses fetch mode when only -x is specified -
> > which imo isn't a very good thing to use due to the increased risk of
> > not fetching everything.
>
On Mon, Aug 25, 2014 at 1:35 PM, Andres Freund wrote:
> Hi,
>
> currently pg_basebackup uses fetch mode when only -x is specified -
> which imo isn't a very good thing to use due to the increased risk of
> not fetching everything.
> How about switching to stream mode for 9.5+?
I think the origina
Mark Kirkwood wrote:
> On 06/05/14 16:28, Amit Kapila wrote:
> >On Mon, May 5, 2014 at 11:57 AM, Mark Kirkwood
> > wrote:
> >I could think of 2 ways to change this:
> >
> >a. if user has specified cost_limit value for table, then it just uses it
> > rather than rebalancing based on value of s
On 8/15/14 7:30 PM, Joachim Wieland wrote:
> Attached is a patch that doesn't add any new functionality or
> features, all it does is get rid of the global variables that
> pg_dump.c is full of.
I'm getting a compiler error:
In file included from pg_dump.c:60:
In file included from ./pg_backup_ar
On Tue, Aug 26, 2014 at 8:40 PM, Tom Lane wrote:
> Amit Kapila writes:
> > Another point is I think it will be better to protect
> > StrategyControl->completePasses with victimbuf_lck rather than
> > freelist_lck, as when we are going to update it we will already be
> > holding the victimbuf_lck
Kevin Grittner wrote:
> Kevin Grittner wrote:
>> "bemanuel...@gmail.com" wrote:
>>
>>> tjma_dw=> set role user_dw;
>>>
>>> tjma_dw=> CREATE TABLE foo_data AS SELECT i, md5(random()::text) FROM
>>> generate_series(1, 10) i;
>>> SELECT 10
>>> tjma_dw=> CREATE MATERIALIZED VIEW mv_foo AS SELE
Amit Kapila writes:
> On Tue, Aug 5, 2014 at 9:21 PM, Robert Haas wrote:
>>> I think you should get rid of BufFreelistLock completely and just
>>> decide that freelist_lck will protect everything the freeNext links, plus
>>> everything in StrategyControl except for nextVictimBuffer. victimbuf_lc
1 - 100 of 150 matches
Mail list logo
