yet another GUC around. Especially when it will probably take multiple
tuning steps before you're done anyway; we don't really know the rest of
them yet; and when we do, we probably won't need a GUC to cope with them
in the end anyway.
--
Greg Smith greg.sm...@crunchydatasolutions.
to avoid going down for two days each time they saw
corruption, where we had to dump/reload to get them going again. If the
install had checksums, I could have figured out which blocks were
damaged and manually fixed them. Without checksums, there really was
nowhere to go except dump/reload.
ere we had to dump/reload to get them going again. If the
install had checksums, I could have figured out which blocks were
damaged and manually fixed them. Without checksums, there's no way to
even tell for sure what is broken.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com
ide your area, etc. I want to
think through some use cases and review the code to see whether that
concept helps or not.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing l
uality review. Did I
miss any big themes on that list?
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
9.4. It would be nice to
see how that fits together today, even if the code for it isn't being
reviewed heavily yet.
I don't quite understand yet what's missing on the writer side. If you
could help explain what's missing there, I would like to read about that.
--
Gre
nagement scheme until the
potential gain is measured.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
eces of plumbing in place first.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
ow much
fsync is happening at any time, that would be useful on all the
platforms that support it. I haven't tried it just because that looked
to me like a large job refactoring the entire fsync absorb mechanism,
and I've never had enough funding to take it on. That approach has a
on. I don't see why that possibility has to block this feature
from being adopted though. That line of thinking leads toward removing
trust authentication, because that's similarly abused with cut and paste
tutorials.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
Post
e on your unsafe list are:
listen_addresses, port, shared_buffers, log_directory, log_filename
Obvious missing thing from your unsafe list that is also changed
regularly is max_connection. I count 6 parameters that are both unsafe
and changed regularly.
--
Greg Smith 2ndQuadrant U
STEM SET should consider
a config directory based approach. But from the perspective of what can
get committed first, the config directory really should go first.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadran
for this feature, and that's now where the
controversial parts are either. That's the part I thought should be
looked at for commit now. I'd like to get the change size Amit is
carrying around and (and other people are reviewing) reduced here.
--
Greg Smith 2ndQ
nking about an older,
now unsupported version of the Debian packaging. Debian packaging
absolutely will want to relocate any new files added here into their
/etc directory tree as well, where they will be writeable. They will
not go into the $PGDATA directory.
--
Greg Smith 2ndQuadrant US
erformance at
http://www.ibm.com/developerworks/linux/library/l-fs8/index.html
Spoiler: if you use a workload that has checkpoint issues, it doesn't
help PostgreSQL latency. Just like using a large write cache, you gain
some burst performance, but eventually you pay for it with extra latency
somew
getting sequential ones to the WAL. But when you crash, expect to be
down for a significant chunk of an hour, as you go back to sort out all
of the work postponed before.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2nd
rdered writes again. SSD
controllers also have firmware that does this sort of work, and Postgres
might do it as part of vacuum cleanup. But note that such work faces
exactly the same problems as writing the data out in the first place.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com
random I/O penalty that's being avoided right now. Checkpoints are
already postponing these random writes as long as possible. You have to
take care of them eventually though.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 2
. There's plenty of bogus
material submitted here. It's the high standards for review and commit
that are the key filter. The importance of the process to the result
isn't weighed as heavily as I think it should be.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com
re has to be more than just the one in a submission of
this size. The rough fairness promises of the CommitFest seem satisfied
to me though.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via
On 7/23/13 10:56 AM, Robert Haas wrote:
On Mon, Jul 22, 2013 at 11:48 PM, Greg Smith wrote:
We know that a 1GB relation segment can take a really long time to write
out. That could include up to 128 changed 8K pages, and we allow all of
them to get dirty before any are forced to disk with
to care about it being right. My eyes were
starting to glaze over by the end of staring at this "flock".
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing l
ale for it to look like
ANALYZE that's helpful too.
I have a project for this summer that includes reviving this topic and
making sure it works on some real-world systems. If you want to work on
this too, I can easily combine that project into what you're doing.
--
Greg Smith 2ndQua
On 7/22/13 10:48 PM, Tom Lane wrote:
Greg Smith writes:
Remove unused targets from plan: Alvaro? (He reviewed it already)
Really I should do that one, but it seems like all my available cycles
have been going into bug fixing lately :-(
I just put you down as the committer on it, given
t
credited at all, and maybe you'll see some small review credit for
benchmarks. That's completely backwards from the actual work ratio. If
all I'm getting out of something is credit, I'd at least like it to be
an appropriate amount of it.
--
Greg Smith 2ndQuadrant USg..
e large sequential disk fields.
I normally increase read-ahead on Linux systems to get faster speed on
sequential disk throughput. Changing the block size might work better
in some cases, but not many people are willing to do that. Read-ahead
is very easy to change at any time.
--
Greg Smit
.conf ("ALTER SYSTEM" patch): Alvaro
volunteered to look at this if no one else gets to it first.
UNNEST() (and other functions) WITH ORDINALITY: Greg Stark
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.
points.
I think that suggests an alternate, secondary output format would be
useful though, rather than that a different default one is a good idea.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent
hing. I think it's more
important to consider whether people are trusted to keep commits within
their known area(s) of expertise.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql
deserve a point. I'd be happy if we
suddenly had a problem where people were doing only that to try game
their leaderboard ranking.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsq
r spending time on
it. (This is a bit much to expect new reviewers to chew on usefully)
I've been working on that here, but I don't have anything I can publicly
commit to yet.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24
uld have
to be disabled there.
That argues that if committed at all, the ability to turn this off I was
asking about would be necessary. It sounds like this *could* work like
how minimal WAL archiving levels allow optimizations that are disabled
at higher ones--like the COPY into a truncated
part of the code seems to have
settled, and things like using the new validate_conf_option could be
committed even with other parts still being discussed. Exactly how to
best break this out into useful commits is another decision that really
needs some input from the potential committer though.
ready from Amit or Hari before the next CF, send them out and I can look
at them without waiting until that one starts. This is a very promising
looking performance feature.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.
edule lag can highlight a
subtle problem there even if the target rate limit is met in the end.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.
uted at the start of each client
too. It's not ever adjusted based on what individual transactions do.
I also noted the way this can cause schedule lag for some time after a
slow transaction finishes, since that's the main issue observed so far.
--
Greg Smith 2ndQuadrant USg
he next feature I'm working on attempts to
quantify the total writes to each 1GB relation chunk. That's the most
promising path forward on the checkpoint problem I've found.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24
data to
talk about this usefully. That's what I consider the bare minimum
evidence to consider changing something here. I have all of those
features in pgbench-tools with checkpoint logging turned way up, but
they're not all in the dbt2 toolset yet as far as I know.
--
Greg S
here.
This useful piece was just presented at PGCon:
http://www.pgcon.org/2013/schedule/attachments/273_PGcon2013-kaigai-row-level-security.pdf
That is very up to date intro to the big picture issues.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Ser
cking is not necessary, it was just trying to make the transition to
the new configuration approach less error-prone. I don't think anyone
would disagree that the current patch is doing enough of that error
checking work that the error checking itself is the most likely thing to
break.
morrow and send out a new version. I'm hopeful that v18
will finally be the one that everyone likes.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list
around the community with HP
controllers--I have even one myself now--but we could use more LSI Logic
and Adaptec based systems.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers ma
needed here now due the
commit that changed this, or if the patch wasn't referring to the right
type of error originally.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mai
mption that ignoring
the contract with the administrator was frowned on by this project. If
people want this sort of behavior in the server, I'm satisfied my
distaste for the idea and the reasoning behind it is clear now.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimor
cating the PostgreSQL code to add a new way to
do that, not when checkpoint_timeout is already there with a direct,
simple control on the exact same trade-off.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
method one day.
The idea of surveying patents in some area so that their methods can be
avoided in code you develop, that is a reasonable private stance to
take. But don't do that on the lists.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Ser
n't break some part of the design too.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ghput. The latency reports from the perspective of Fabien's code
were always reasonable though. When something delays every client, it
counts that against every active client's lag, and that's the right
thing to do.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com B
, the effect of changes like this has always averaged out to
zero. You should try it sometime. Then we can have a useful discussion
of non-trivial results instead of you continuing to tell me I don't
understand things.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Bal
nough in a case like this
that the user will see they tried to limit at 1, but they only got
7135, so something must not have worked as expected.
Tatsuo: most of my tests were on Mac OS and Linux, I actually tested
the Mac version a lot more than any other here. I didn't do any
or worse, as a simple example of where a positive change in one
area can backfire badly on another workload. That particular problem
was so common I updated pgbench-tools recently to track table
maintenance time between tests, because that demonstrated an issue even
when the TPS numbers
un or not.
This little hack moved around how clients finished enough to get rid of
the weird issue with your patch I was bothered by. You may be right
that the change isn't really correct because of how the connection is
compared to null as a way to see if it's active. I initially added
ssible, because creating the trigger is the
signalling mechanism.
I don't think there needs to be a CLI interface for putting the
alternate possible text into the trigger--that you can ask for 'fast'
startup. It's nice to have available as an expert, but it's fine for
outperforming the filesystem, it is very difficult to realize. There's
a good reason that companies like Oracle stopped pushing so hard on
recommending raw partitions.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x
umber of pgbench tests to get enough evidence of improvement to
commit. I can help with that part when you get to something I haven't
tried already. I am very interesting in improving this area, it just
takes a lot of work to do it.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Bal
rite and the fsync
call that eventually flushes it out are very disconnected right now, and
file range data seems the right missing piece to connect them well.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadr
On 7/14/13 2:48 PM, Fabien COELHO wrote:
You attached my v13. Could you send your v14?
Correct patch (and the little one from me again) attached this time.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www
On 6/27/13 11:08 AM, Robert Haas wrote:
I'm pretty sure Greg Smith tried it the fixed-sleep thing before and
it didn't work that well.
That's correct, I spent about a year whipping that particular horse and
submitted improvements on it to the community.
http://www.postgresql
fferent between two tests, I have to throw them out as unfair. A lot
of things that seem promising turn out to have this sort of problem.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsq
versions of
pgbench, and I don't think there's enough benefit to the float format to
bother breaking them today.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
diff --git a/contrib/pgbench/
he throttling code,
and then this all should wrap up nicely. I'd like to get this one out
of the commitfest so I can move onto looking at something else.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadr
ed to it yet. I've basically gotten what I wanted to here
from this submission; I'm marking it returned with feedback. If anyone
else has comments, I'm still open to discussion here too.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Se
ed in glibc) or significantly faster (if
implemented in the kernel).
That's what I'm seeing everywhere too. I'm happy that we've spent
enough time chasing after potential issues without finding anything now.
Pull out the GUC that was added for default and this is ready to commit.
ng toward saying that unless there's a clear regression on older
platforms, above the noise floor, this is still the right thing to do.
I fully agree that this needs to fully automatic--no GUC--before it's
worth committing. If we can't figure out the right thing to do now,
there&
lts on the
new platforms, the old ones need to just not get worse.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
I'm not sure how it behaved for you here.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
posix_fallocate approach is actually slower than what's done now when
it's not getting kernel acceleration, which is the case on RHEL5 era
kernels, we might need to make the configure time test more complicated.
Whether posix_fallocate is defined isn't sensitive enough; on L
ture since I started
instrumenting my copy more heavily. I hope I can get this ready for
commit by Monday. I've certainly beaten on the feature for long enough now.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQu
long pause between background writer runs.
This refactoring idea will make that hard to keep around. I think this
is OK though. Switching to a latch based design should eliminate the
bgwriter_delay, which means you won't have this worst case of a 200ms
stall while heavy acti
s who don't do enough review.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
oCustom() code. st->listen goes to 1 very soon after startup
and then it stays there, and that logic seems fine too.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
#!/bin/bash
make
make install
rm pgbench
trandom aid 1 :naccounts
1371238832.085903 client 12 sending SELECT abalance FROM
pgbench_accounts WHERE aid = 299080;
1371238832.086587 client 12 receiving
1371238832.086662 calling select
1371238832.231032 client 12 receiving
1371238832.231032 client 12 finished
Investigation is still going here...
quot; command, and the way that delay is
handled happens inside threadRun() instead. The pausing of the rate
limit throttle needs to operate in the same place. I have to redo a few
things to confirm this actually fixes the issue, as well as look at
Fabien's later updates to this since I
7;m planning to duplicate Jon's test program on a few machines here, and
then see if that turns into a useful latency improvement for clients.
I'm trying to get this pgbench rate limit stuff working first though,
because one of the tests I had in mind for WAL creation overhead would
benefit
That is how I was evaluating the smoothness of the rate limit, by
graphing those latency values. pgbench-tools takes those and a derived
TPS/s number and plots them, which made it easier for me to spot this
weirdness. But I've already moved onto analyzing the raw latency data
instead, I
he startup timing.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
On 6/11/13 12:22 PM, Merlin Moncure wrote:
Personally I think this patch should go in regardless -- the concerns
made IMNSHO are specious.
That's nice, but we have this process for validating whether features go
in or not that relies on review instead of opinions.
--
Greg
27;ve
done here, but it seems like a whole class of new bugs and potential
bottlenecks could come out of that. Whenever someone touches the
threading model for pgbench it usually gives a stack of build farm
headaches. Better to avoid those unless there's really a compelling
re
is when pressure increases at
the top.
The way this discussion has wandered off has nicely confirmed I was
right to try and avoid going into this area again :(
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadr
n. I haven't put a hard
number to measuring it directly, but systems with vacuum problems seem
more likely to have noticeable filesystem level fragmentation. I've
been thinking about collecting data from a few systems with filefrag to
see if I'm right about that.
--
Greg Sm
t now.
I suspect the reason we don't see as many complaints is that a lot more
systems can handle 7.8MB/s of random reads then there are ones that can
do 3.9MB/s of random writes. If we removed that read limit, a lot more
complaints would start rolling in about the read side.
--
kpoint_segments is turning into an internal implementation detail
most sites I see wouldn't miss at all. Rather than put work into
autotuning it, I'd be happy to eliminate checkpoint_segments altogther,
in favor of a WAL disk space limit.
--
Greg Smith 2ndQuadrant USg...@2ndquadr
tra carriage return characters in your last
submission. Wasn't a problem this time, but if you can get rid of those
that makes for a better patch.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
<
ted to ask people to grapple with that pair.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
here's finally enough dedicated hardware
around to see the issue and work on it, but I haven't gotten a clear
picture of any reproducible test workload that gets slower with large
buffer cache sizes. If anyone has a public test case that gets slower
when shared_buffers goes
here checkpoint_timeout is
15 minutes (and can be no shorter without checkpoint spikes). At no
point during that fairly difficult but of tuning work did
checkpoint_segments do anything but get in the way.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Trai
ency is to crank up the background
writer and let it try to stay ahead of backends with the writes. The
checkpointer won't have nearly as much work to do in that situation.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQ
On 5/30/13 11:21 AM, Alvaro Herrera wrote:
Greg Smith escribió:
The messy part of extending relations in larger chunks
is how to communicate that back into the buffer manager usefully.
The extension path causing trouble is RelationGetBufferForTuple
calling ReadBufferBI. All of that is passing
27;s a pain to
write the code.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
tical that this sort
of API may not work exactly as specified. If you're willing to believe
the spec, that's fine, but I think that's dangerously optimistic.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support
l they are
explicitly validated: http://lwn.net/Articles/350225/
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
files are
good I have to assume they're not.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
On 5/28/13 10:00 PM, Jon Nelson wrote:
On Tue, May 28, 2013 at 10:36 AM, Greg Smith wrote:
On 5/28/13 11:12 AM, Jon Nelson wrote:
It opens a new file, fallocates 16MB, calls fdatasync.
Outside of the run for performance testing, I think it would be good at this
point to validate that
faster"
claims that don't come with any repeatable measurements at all. Very
often theories about the fastest way to do something don't match what's
actually seen in testing.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Servic
they work. Exactly what parameters
and logic fires when they are called can easily be refactored later.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hacker
um are completely
feasible on UNIX-like systems. The work to insert a cost delay point
needs to get done before building more complicated logic on top of it
though, so I'm starting with this part.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, S
lay's test. That's a guess though. I'll have to think about
this more when I circle back toward usability. Thanks for the
implementation idea.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
inding priority
inversion issues is an interesting idea. It's a bit down the road from
what I'm staring at now though.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers ma
will be time consuming (if not impossible) to eliminate. The
person who runs an exclusive CLUSTER that's limited by
statement_cost_delay may suffer from holding the lock too long. But
that might be their intention with setting the value. Hard to idiot
proof this without eliminating useful
are not more symmetrical.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
1 - 100 of 1570 matches
Mail list logo
