On 12/16/13 9:36 AM, Craig Ringer wrote:
- Finish and commit updatable security barrier views. I've still got a
lot of straightening out to do there.
I don't follow why you've put this part first. It has a lot of new
development and the risks that go along with that, but the POC projects
I've
On 12/19/13 5:52 PM, Gavin Flower wrote:
Curious, wouldn't the common usage pattern tend to favour a skewed
distribution, such as the Poisson Distribution (it has been over 40
years since I studied this area, so there may be better candidates).
Some people like database load testing with a
On 12/18/13 10:21 PM, Craig Ringer wrote:
In the end, sometimes I guess there's no replacement for WHERE
call_some_procedure()
That's where I keep ending up at. The next round of examples I'm
reviewing this week plug pl/pgsql code into that model. And the one
after that actually references
On 12/13/13 11:40 PM, Craig Ringer wrote:
You may want to check out the updated writable security-barrier views patch.
http://www.postgresql.org/message-id/52ab112b.6020...@2ndquadrant.com
It may offer a path forward for the CF submission for RLS, letting us
get rid of the var/attr fiddling
On 1/17/14 10:37 AM, Mel Gorman wrote:
There is not an easy way to tell. To be 100%, it would require an
instrumentation patch or a systemtap script to detect when a
particular page is being written back and track the context. There are
approximations though. Monitor nr_dirty pages over time.
On 1/20/14 9:46 AM, Mel Gorman wrote:
They could potentially be used to evalate any IO scheduler changes.
For example -- deadline scheduler with these parameters has X
transactions/sec throughput with average latency of Y millieseconds
and a maximum fsync latency of Z seconds. Evaluate how
On 4/7/14 2:59 AM, Craig Ringer wrote:
On 04/05/2014 03:57 AM, Andres Freund wrote:
c07) Updatable security barrier views.
This needs a serious look by a committer.
I've been exercising it via row security and it's been looking pretty
solid. It isn't a huge or intrusive patch, and it's
On 4/6/14 2:46 PM, Pavel Stehule wrote:
Proposed options are interesting for enterprise using, when you have
a some more smart tools for log entry processing, and when you need a
complex view about performance of billions queries - when cancel time
and lock time is important piece in mosaic
On 4/9/14 9:56 PM, Stephen Frost wrote:
As for docs and testing, those are things we would certainly be better
off with and may mean that this isn't able to make it into 9.4, which is
fair, but I wouldn't toss it out solely due to that.
We have a git repo with multiple worked out code
On 6/11/14, 10:26 AM, Robert Haas wrote:
Now, as soon as we introduce the concept that selecting from a table
might not really mean read from the table but read from the table
after applying this owner-specified qual, we're opening up a whole
new set of attack surfaces. Every pg_dump is an
On 9/11/14, 7:01 AM, Andres Freund wrote:
I'm not convinced that these changes can be made without also changing
the bgwriter logic. Have you measured whether there are differences in
how effective the bgwriter is? Not that it's very effective right now :)
The current background writer tuning
On 9/10/14, 10:57 AM, Fabien COELHO wrote:
Indeed. I think that people do not like it to change. I remember that
I suggested to change timestamps to .yy instead of the
unreadable yyy, and be told not to, because some people have
tool which process the output so the format MUST NOT
On 9/12/14, 2:28 PM, Robert Haas wrote:
I hate to be the guy always suggesting a mini-language (cf. recent
discussion of an expression syntax for pgbench), but we could do much
more powerful and flexible things here if we had one. For example,
suppose we let each element of
On 8/28/14, 12:18 PM, Robert Haas wrote:
At least in situations that I've encountered, it's typical to be able
to determine the frequency with which a given table needs to be
vacuumed to avoid runaway bloat, and from that you can work backwards
to figure out how fast you must process it in
On 9/16/14, 8:18 AM, Amit Kapila wrote:
I think the main reason for slight difference is that
when the size of shared buffers is almost same as data size, the number
of buffers it needs from clock sweep are very less, as an example in first
case (when size of shared buffers is 12286MB), it
On 9/23/14, 9:00 AM, Andres Freund wrote:
I also think committers need to be much more careful when committing
patches which they (or their employer) appear to have a business
interest in. Rushing ahead to commit the patch of somebody 'unrelated'
leaves a completely different taste than
On 9/23/14, 10:31 AM, Robert Haas wrote:
I suggest we count these things:
1. The number of buffers the reclaimer has put back on the free list.
2. The number of times a backend has run the clocksweep.
3. The number of buffers past which the reclaimer has advanced the
clock sweep (i.e. the
On 9/23/14, 8:02 PM, Michael Paquier wrote:
pgsql-hackers is as well a mailing list where people have technical
discussions about features and patches, hence your question would be
more adapted for pgsql-novice or pgsql-general.
Let's be fair and get the details perfect if we're going to
On 9/23/14, 1:21 AM, David Johnston wrote:
This patch should fix the round-to-zero issue. If someone wants to
get rid of zero as a special case let them supply a separate patch for
that improvement.
I am going to wander into this fresh after just reading everything once
(but with more than
On 9/23/14, 10:52 PM, David Johnston wrote:
Given the following why not just pick ms for log_rotation_age now?
Right now there are people out there who have configurations that look
like this:
log_rotation_age=60
In order to get hourly rotation. These users will suffer some trauma
On 9/23/14, 7:13 PM, Robert Haas wrote:
I think we expose far too little information in our system views. Just
to take one example, we expose no useful information about lwlock
acquire or release, but a lot of real-world performance problems are
caused by lwlock contention.
I sent over a
On 9/24/14, 6:45 PM, Peter Eisentraut wrote:
But then this proposal is just one of several others that break backward
compatibility, and does so in a more or less silent way. Then we might
as well pick another approach that gets closer to the root of the problem.
I was responding to some
On 9/24/14, 10:10 PM, Robert Haas wrote:
I think you're making a mountain out of a molehill. I implemented this
today in about three hours.
I think you're greatly understating your own efficiency at
shift/reducing parser mountains down to molehills. Fabien even guessed
the LOC size of the
On 9/25/14, 1:41 AM, David Johnston wrote:
If the error message is written correctly most people upon seeing the
error will simply fix their configuration and move on - regardless of
whether they were proactive in doing so having read the release notes.
The important part to realize here is
On 9/25/14, 8:38 AM, Robert Haas wrote:
That's my whole reason for not wanting to adopt Fabien's approach in
the first place: I was cool with exposing C's modulo operator, but any
other modulo semantics seem like they should be built up from
general-purpose primitives.
Maybe; I don't quite
On 9/25/14, 2:02 PM, Peter Eisentraut wrote:
But having the same parameter setting mean different things in
different versions is the path to complete madness.
Could we go so far as to remove support for unitless time settings
eventually? The fact that people are setting raw numbers in the
On 9/26/14, 2:17 PM, Tom Lane wrote:
Well, ok, let's allow zero as a special case, but it has to be written
as 0 not something else. If you try to set a positive value then we
should act as though the min_val is 1 unit. So I'm coming around to
the idea that throw an error if a nonzero input
On 9/26/14, 2:34 PM, David Johnston wrote:
I don't get where we need to do anything else besides that...the
whole actual min values comment is unclear to me.
If you look at pg_settings, there is a minimum value exposed there as
min_val. For some of these parameters, that number would
On 9/26/14, 2:50 PM, David G Johnston wrote:
Like I said I just want to fix the bug and call it a day :)
I'm afraid you've come to the wrong project and mailing list for *that*.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 9/26/14, 2:38 PM, Gavin Flower wrote:
Curious: would it be both feasible and useful to have multiple workers
process a 'large' table, without complicating things too much? The
could each start at a different position in the file.
Not really feasible without a major overhaul. It might be
On 9/26/14, 3:22 PM, Tom Lane wrote:
We could alternatively try to split up these cases into multiple GUCs,
which I guess is what you're imagining as a multi-year battle.
No, I was just pointing out that even the cleanest major refactoring
possible here is going to result in broken config
On 9/27/14, 4:18 AM, Heikki Linnakangas wrote:
add latency limit to pgbench throttling (--rate)
---
Rukh: Are you planning to review the latest patch version?
Rukh is free to jump onto this ASAP, but if it's still there next week I
already had my eye on picking that up and taking it out for a
On 9/28/14, 7:49 AM, Bogdan Pilch wrote:
I have created a small patch to postgres source (in particular the
psql part of it) that modifies the way time spent executing the SQL
commands is printed out.
The idea is to have a human readable time printed
There are already a wide range of human
On 9/29/14, 2:30 PM, Andres Freund wrote:
Can we explain those reasons in the form of documentation?
Yes. Try and benchmark it. It'll be hardware and workload dependant.
I missed this whole thing, and eventually I have to circle back to it.
I could do it this week. Could you (or someone
On 9/29/14, 1:08 AM, Andres Freund wrote:
On 2014-09-28 20:32:30 -0400, Gregory Smith wrote:
There are already a wide range of human readable time interval output
formats available in the database; see the list at
http://www.postgresql.org/docs/current/static/datatype-datetime.html#INTERVAL
On 10/3/14, 8:26 AM, Andres Freund wrote:
#define NUM_XLOGINSERT_LOCKS 1
tps = 52.711939 (including connections establishing)
#define NUM_XLOGINSERT_LOCKS 8
tps = 286.496054 (including connections establishing)
#define NUM_XLOGINSERT_LOCKS 16
tps = 346.113313 (including connections
On 10/3/14, 10:11 AM, Andres Freund wrote:
So 25% performance on a relatively small machine improvements aren't
worth a GUC? That are likely to be larger on a bigger machine? I
utterly fail to see why that's a service to our users.
I didn't say that. I said I don't think they're worth a GUC
On 10/3/14, 5:23 PM, Andres Freund wrote:
How are we ever going to be able to tune it further without feedback
from actual production usage?
With improved targeted synthetic test cases that isolate the bottleneck
to where it's really obvious, way more obvious than it will ever be in
On 8/13/14, 5:14 AM, MauMau wrote:
I'm interested in b, too. I was thinking of proposing a performance
diagnostics feature like Oracle's wait events (V$SYSTEM_EVENT and
V$SESSION_EVENT). So, if you do this, I'd like to contribute to the
functional design, code and doc review, and testing.
On 10/13/14, 1:54 PM, Heikki Linnakangas wrote:
Greg Smith, I'd still appreciate it if you could take a look at this,
to check how this will work for pgbench-tools.
I'll do a QA pass on the committed version looking for issues, and
update the toolchain I publish to be compatible with it along
40 matches
Mail list logo
