On Fri, Jul 19, 2013 at 8:34 AM, Tom Lane wrote:
> Jeff Janes writes:
> > AGG_PLAIN sometimes does sorts, but it thinks they are free. Also, under
> > explain analyze it does not explicitly report whether the sort was
> external
> > or not, nor report the disk or memory usage, the way other sor
The server is already turned off and in our nyc office (I'm based in the
ldn one). But I'm pretty sure its a LSI MegaRAID SAS 9285.
On Thu, Jul 18, 2013 at 11:58 PM, Greg Smith wrote:
> On 7/10/13 12:53 PM, Benedikt Grundmann wrote:
>
>> The server will probably be most interesting for the dis
I'm not a native English speaker either... Greg, could you please
review the document?
Yes, I already took at look at it briefly. The updates move in the right
direction, but I can edit them usefully before commit.
Great, thanks for your help!
--
Fabien.
--
Sent via pgsql-hackers mailin
Alvaro Herrera wrote:
> This is a preliminary proposal for Minmax indexes. I'm experimenting
> with the code, but it's too crude to post yet, so here's a document
> explaining what they are and how they work, so that reviewers can poke
> holes to have the design improved.
After going further wit
Noah Misch writes:
> To me, the major advantage of removing SnapshotNow is to force all
> third-party code to reevaluate. But that could be just as well
> achieved by renaming it to, say, SnapshotImmediate. If there are
> borderline-legitimate SnapshotNow uses in our code base, I'd lean
> toward
On Friday, July 19, 2013 4:11 AM Greg Smith wrote:
>On 7/9/13 12:09 AM, Amit Kapila wrote:
>>I think the first thing to verify is whether the results posted can be
>> validated in some other environment setup by another person.
>>The testcase used is posted at below link:
>>http://www
On Friday, July 19, 2013 1:33 AM Alvaro Herrera wrote:
> Fujii Masao escribió:
> > On Fri, Jul 19, 2013 at 2:45 AM, Josh Berkus
> wrote:
> > > On 07/18/2013 04:25 AM, Amit Kapila wrote:
> > >> On Thursday, July 18, 2013 12:38 AM Josh Berkus wrote:
> > >>> On 07/17/2013 12:01 PM, Alvaro Herrera wro
On Thu, Jul 18, 2013 at 08:46:48AM -0400, Robert Haas wrote:
> 1. snapshot-error-v1.patch introduces a new special snapshot, called
> SnapshotError. In the cases where we set SnapshotNow as a sort of
> default snapshot, this patch changes the code to use SnapshotError
> instead. This affects scan
Greg,
> I thought this was a good spot to try and re-draw this line because I
> don't want just one program that is able to create new configuration
> entries easily. I want to see a whole universe of them. ALTER SYSTEM
> SET, tuning helpers, replication helpers, logging helpers, vacuum
> schedu
Noah Misch writes:
> On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote:
>> It's always annoyed me that pgindent insists on adjusting vertical
>> whitespace around #else and related commands. This has, for example,
>> rendered src/include/storage/barrier.h nigh illegible: you get things
>>
On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote:
> It's always annoyed me that pgindent insists on adjusting vertical
> whitespace around #else and related commands. This has, for example,
> rendered src/include/storage/barrier.h nigh illegible: you get things
> like
>
> /*
> * lwsync o
On 7/18/13 11:03 PM, Stephen Frost wrote:
Wasn't there a wiki page about this
feature which might also help? Bigger question- is it correct for the
latest version of the patch?
https://wiki.postgresql.org/wiki/RLS has accumulated a lot of older
debris that may or may not be useful here.
Thi
* Greg Smith (g...@2ndquadrant.com) wrote:
> On 7/18/13 7:57 PM, Karol Trzcionka wrote:
> >Current head 4cbe3ac3e86790d05c569de4585e5075a62a9b41 -> patch applies
> >correct (only change needed in parallel_schedule).
> >However it fails on own regression tests (other tests pass).
>
> I got a reject
Jeff Janes writes:
> AGG_PLAIN sometimes does sorts, but it thinks they are free. Also, under
> explain analyze it does not explicitly report whether the sort was external
> or not, nor report the disk or memory usage, the way other sorts do. I
> don't know if those two things are related or not
AGG_PLAIN sometimes does sorts, but it thinks they are free. Also, under
explain analyze it does not explicitly report whether the sort was external
or not, nor report the disk or memory usage, the way other sorts do. I
don't know if those two things are related or not.
This behavior seems to be
"Prabakaran, Vaishnavi" writes:
> The specific use case which I am interested in is
> " Numeric LIKE Pattern_string ".
> I'm willing to attempt a patch to support the specific use case above by
> adding implicit casts, without modifying the entire casting rules.
> Is this something that is li
Hi,
Thanks for your responses.
The specific use case which I am interested in is
" Numeric LIKE Pattern_string ".
I'm willing to attempt a patch to support the specific use case above by adding
implicit casts, without modifying the entire casting rules.
Is this something that is likely to be
Noah Misch writes:
> (I don't know whether VARIADIC transition functions work today, but that would
> become an orthogonal project.)
Coincidentally enough, some Salesforce folk were asking me about allowing
VARIADIC aggregates just a few days ago. I experimented enough to find
out that if you ma
On Thu, Jul 18, 2013 at 10:33:15PM +, Andrew Gierth wrote:
> Josh Berkus wrote:
> > Well, seems like it would work the same as
> >
> > agg_func(constx,coly,colz ORDER BY coly, colz)
I'd try transforming WITHIN GROUP into the above during parse analysis. The
default would be the transform
Greg,
* Greg Smith (g...@2ndquadrant.com) wrote:
> That seems easy enough to do here, Heikki's test script is
> excellent. The latest patch Hari posted on July 2 has one hunk that
> doesn't apply anymore now. Inside
> src/backend/utils/adt/pg_lzcompress.c the patch tries to change this
> code:
>
Peter Eisentraut writes:
> The new jsonfuncs.c has some confusing typedef scheme. For example, it
> has a bunch of definitions like this:
> typedef struct getState
> {
> ...
> } getState, *GetState;
> So GetState is a pointer to getState. I have never seen that kind of
> convention before.
The new jsonfuncs.c has some confusing typedef scheme. For example, it
has a bunch of definitions like this:
typedef struct getState
{
...
} getState, *GetState;
So GetState is a pointer to getState. I have never seen that kind of
convention before.
This then leads to code like
GetState
Folks,
Please find attached a PoC patch to implement $subject.
So far, with a lot of help from Andrew Gierth, I've roughed out an
implementation which allows you to ALTER FOREIGN TABLE so it inherits
a local table.
TBD: CREATE FOREIGN TABLE ... INHERITS ..., docs, regression testing,
etc., etc.
W dniu 19.07.2013 02:42, Tom Lane pisze:
> Hm, what compiler version are you using? I've never seen such a
> warning (and that code hasn't changed in some time).
gcc version 4.8.1 20130612 (Red Hat 4.8.1-2) (GCC)
Regards,
Karol
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
Karol Trzcionka writes:
> in the current master head (4cbe3ac3e86790d05c569de4585e5075a62a9b41),
> I've noticed the compiler warnings in src/backend/utils/mb/conv.c
Hm, what compiler version are you using? I've never seen such a warning
(and that code hasn't changed in some time).
I agree the c
Hi!
On 2013-07-19 07:31:07 +0900, Michael Paquier wrote:
> If this behavior is confirmed, I think that this bug should be
> reported directly to Andres and not this mailing list, just because
> logical replication is not integrated into Postgres core as of now.
I think I agree, although I don't k
On 7/18/13 4:02 PM, Alvaro Herrera wrote:
I think we should just put the config directives of ALTER SYSTEM into a
file, not dir, alongside postgresql.conf; I would suggest
postgresql.auto.conf. This file is parsed automatically after
postgresql.conf, without requiring an "include" directive in
Hello,
in the current master head (4cbe3ac3e86790d05c569de4585e5075a62a9b41),
I've noticed the compiler warnings in src/backend/utils/mb/conv.c
conv.c: In function ‘UtfToLocal’:
conv.c:252:23: error: ‘iutf’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
...
conv.c: In func
(2013/07/18 23:54), Robert Haas wrote:
On Thu, Jul 18, 2013 at 10:34 AM, Tom Lane wrote:
Robert Haas writes:
1. snapshot-error-v1.patch introduces a new special snapshot, called
SnapshotError. In the cases where we set SnapshotNow as a sort of
default snapshot, this patch changes the code to
Current head 4cbe3ac3e86790d05c569de4585e5075a62a9b41 -> patch applies
correct (only change needed in parallel_schedule).
However it fails on own regression tests (other tests pass).
Regards,
Karol
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
Jeevan Chalke writes:
>>> Following example does not work as expected:
>>>
>>> -- Should return TRUE but returning FALSE
>>> SELECT 'Programmer' ~ '(\w).*?\1' as t;
For the archives' sake --- I've filed a report about this with the Tcl
crew. They seem to have moved their bugtracker recently; it
On 7/18/13 6:45 PM, Tatsuo Ishii wrote:
I'm not a native English speaker either... Greg, could you please
review the document?
Yes, I already took at look at it briefly. The updates move in the
right direction, but I can edit them usefully before commit. I'll have
that done by tomorrow and
On 7/10/13 12:53 PM, Benedikt Grundmann wrote:
The server will probably be most interesting for the disks in it. That
is where we spend the largest amount of time optimizing (for sequential
scan speed in particular):
22x600GB disks in a Raid6+0 (Raid0 of 2x 10disk raid 6 arrays) + 2 spare
disks.
Will revise and re-resubmit for the next CF.
Regards,
2013/07/19 1:06, Alvaro Herrera wrote:
What happened to this patch? We were waiting on an updated version from
you.
Satoshi Nagayasu wrote:
(2012/12/10 3:06), Tomas Vondra wrote:
On 29.10.2012 04:58, Satoshi Nagayasu wrote:
2012/10/24
> Hello Tatsuo
>
>> I think current measurement method will give enough confusion if it's
>> not provided with detailed explanation. Could you please provide doc
>> updatation?
>
> Please find a v17 proposition with an updated and extended
> documentation, focussed on clarifying the lag measure a
On 7/9/13 12:09 AM, Amit Kapila wrote:
I think the first thing to verify is whether the results posted can be
validated in some other environment setup by another person.
The testcase used is posted at below link:
http://www.postgresql.org/message-id/51366323.8070...@vmware.com
That s
> The problem is, given that the parser is looking at:
>
> foo(p1,p2,...) within group (order by q1,q2,...)
>
> how do we best represent the possible matching functions in pg_proc
> and pg_aggregate? Our partial solution so far does not allow
> polymorphism to work properly, so we need a bette
Josh Berkus wrote:
> Hah, I didn't realize that our ordered aggregate syntax even *was* spec.
The spec defines agg(x order by y) only for array_agg and xmlagg; the
generalization to arbitrary other aggregates is our extension. (But
kind of obvious really.)
> > Our implementation does heavily reus
On Fri, Jul 19, 2013 at 5:02 AM, Indrajit Roychoudhury
wrote:
> Could you please let me know what does the error "system identifiers are
> same" mean? Below is the snapshot from one of the masters.
> I am setting up BDR as per the wiki
> http://wiki.postgresql.org/wiki/BDR_User_Guide#Initial_set
On Thu, Jul 18, 2013 at 9:14 AM, Pavel Stehule wrote:
> Hello
>
> I found a slow query with large external sort. I expect, so external
> sort should be penalized. Is it?
It tries to, but it doesn't seem to be much good at it. In
particular, I think it does a poor job of estimating the CPU cost o
Josh Berkus wrote:
> Revive Line Type:
> https://commitfest.postgresql.org/action/patch_view?id=1154
This one's easy -- we're waiting on a decision on whether to use A,B,C
text representation. Honestly, it seems a no-brainer to me that this is
what it should use; the other representation seems t
Josh Berkus escribió:
> We are missing one feature, which is the ability to relocate the
> postgresql.auto.conf file if relocating it is desireable according to
> some sysadmin spec. This kind of ties into another patch which was
> discussed on this list -- the ability to relocate the recovery.co
Hackers,
The following three patches really really need some code review love.
Until they get a code review, we can't close out the CommitFest:
Row-Level Security:
https://commitfest.postgresql.org/action/patch_view?id=874
Revive Line Type:
https://commitfest.postgresql.org/action/patch_view?id=
Dean,
* Stephen Frost (sfr...@snowman.net) wrote:
> Thanks! This is really looking quite good, but it's a bit late and I'm
> going on vacation tomorrow, so I didn't quite want to commit it yet. :)
Apologies on this taking a bit longer than I expected, but it's been
committed and pushed now. Pl
Andrew,
> Well, as you probably know, the spec is a whole pile of random
> special-case syntax and any similarities are probably more accidental
> than anything else.
Hah, I didn't realize that our ordered aggregate syntax even *was* spec.
> A major difference is that in agg(x order by y), the v
Josh Berkus wrote:
> On 07/17/2013 08:15 PM, Andrew Gierth wrote:
> > The spec defines two types of aggregate function classed as "ordered set
> > function", as follows:
> >
> > 1. An "inverse distribution function" taking one argument (which must be
> >a grouped column or otherwise constant
Alvaro,
> I think the only drawback of this is that there's no way to disable
> ALTER SYSTEM (i.e. there's no directory you can remove to prevent the
> thing from working). But is this a desirable property? I mean, if we
> want to disallow ALTER SYSTEM I think we should provide a direct way to
>
Hi,
Could you please let me know what does the error "system identifiers are
same" mean? Below is the snapshot from one of the masters.
I am setting up BDR as per the wiki
http://wiki.postgresql.org/wiki/BDR_User_Guide#Initial_setup
and source @
git://git.postgresql.org/git/users/andresfreund/p
Fujii Masao escribió:
> On Fri, Jul 19, 2013 at 2:45 AM, Josh Berkus wrote:
> > On 07/18/2013 04:25 AM, Amit Kapila wrote:
> >> On Thursday, July 18, 2013 12:38 AM Josh Berkus wrote:
> >>> On 07/17/2013 12:01 PM, Alvaro Herrera wrote:
> Both of these seem like they would make troubleshooters'
Dear Developers.
Could you do things written in this message ?
/// +/* Target
auditorium of this doc are: developers the Postgresql, developers apps c/c++,
paranoiacs . A hosting(dedicted/virtual) is not safe place for storing the
On 07/17/2013 08:15 PM, Andrew Gierth wrote:
> The spec defines two types of aggregate function classed as "ordered set
> function", as follows:
>
> 1. An "inverse distribution function" taking one argument (which must be
>a grouped column or otherwise constant within groups) plus a sorted
>
* Greg Smith (g...@2ndquadrant.com) wrote:
> The first word that comes to mind for for just disregarding the end
> time is that it's a sloppy checkpoint. There is all sorts of sloppy
> behavior you might do here, but I've worked under the assumption
> that ignoring the contract with the administra
On Fri, Jul 19, 2013 at 2:45 AM, Josh Berkus wrote:
> On 07/18/2013 04:25 AM, Amit Kapila wrote:
>> On Thursday, July 18, 2013 12:38 AM Josh Berkus wrote:
>>> On 07/17/2013 12:01 PM, Alvaro Herrera wrote:
Both of these seem like they would make troubleshooters' lives more
difficult. I t
On Thu, Jul 18, 2013 at 1:49 PM, Rushabh Lathia
wrote:
>
>
>
> On Thu, Jul 18, 2013 at 9:40 AM, Satoshi Nagayasu wrote:
>>
>> (2013/07/18 2:31), Fujii Masao wrote:
>>>
>>> On Tue, Jul 16, 2013 at 3:00 PM, Satoshi Nagayasu
>>> wrote:
(2013/07/04 3:58), Fujii Masao wrote:
>
> For
Pavel Stehule writes:
> I found a slow query with large external sort. I expect, so external
> sort should be penalized. Is it?
See cost_sort() in src/backend/optimizer/path/costsize.c
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
Hey folks, this corrects typos going back to
75c6519ff68dbb97f73b13e9976fb8075bbde7b8 where EUC_JIS_2004 and SHIFT_JIS_2004
were first added.
These typos are present in all supported major versions of PostgreSQL, back
through 8.3; I didn't look any further than that. :-)
0001-Doc-patch-for-
On Thu, Jul 18, 2013 at 10:19 AM, Tom Lane wrote:
>
> > Because simpler code is less likely to have bugs and is easier to
> > maintain.
>
> I agree with that point, but one should also remember Polya's Inventor's
> Paradox: the more general problem may be easier to solve. That is, if
> done righ
On 07/18/2013 04:25 AM, Amit Kapila wrote:
> On Thursday, July 18, 2013 12:38 AM Josh Berkus wrote:
>> On 07/17/2013 12:01 PM, Alvaro Herrera wrote:
>>> Both of these seem like they would make troubleshooters' lives more
>>> difficult. I think we should just parse the auto file automatically
>>> a
On 7/18/13 12:00 PM, Alvaro Herrera wrote:
I think the idea is to have a system in which most of the time the
recovery time will be that for checkpoint_timeout=5, but in those
(hopefully rare) cases where checkpoints take a bit longer, the recovery
time will be that for checkpoint_timeout=6.
I
On Thu, Jul 18, 2013 at 12:25 PM, Alvaro Herrera
wrote:
> Ah, yeah, that does show up. I had grepped for 'currtid_'. Sorry.
> They're all in positioned_load() in results.c.
Well, in that case, we'll have to keep it around. I still wish we
could get a clear answer to the question of how it's be
Andres Freund escribió:
> On 2013-07-18 12:01:39 -0400, Robert Haas wrote:
> > On Thu, Jul 18, 2013 at 11:54 AM, Alvaro Herrera
> > wrote:
> > > They don't show up in a quick grep of psqlodbc's source code, FWIW.
> >
> > Hmm. Maybe we should just remove them and see if anyone complains.
> > We c
Hello
I found a slow query with large external sort. I expect, so external
sort should be penalized. Is it?
Regards
Pavel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
What happened to this patch? We were waiting on an updated version from
you.
Satoshi Nagayasu wrote:
> (2012/12/10 3:06), Tomas Vondra wrote:
> >On 29.10.2012 04:58, Satoshi Nagayasu wrote:
> >>2012/10/24 1:12, Alvaro Herrera wrote:
> >>>Satoshi Nagayasu escribi�:
> >>>
> With this patch, w
On 2013-07-18 12:01:39 -0400, Robert Haas wrote:
> On Thu, Jul 18, 2013 at 11:54 AM, Alvaro Herrera
> wrote:
> > They don't show up in a quick grep of psqlodbc's source code, FWIW.
>
> Hmm. Maybe we should just remove them and see if anyone complains.
> We could always put them back (or make the
On Thu, Jul 18, 2013 at 11:54 AM, Alvaro Herrera
wrote:
> They don't show up in a quick grep of psqlodbc's source code, FWIW.
Hmm. Maybe we should just remove them and see if anyone complains.
We could always put them back (or make them available via contrib) if
it's functionality someone actual
Greg Smith escribió:
> On 7/18/13 11:04 AM, Robert Haas wrote:
> >On a system where fsync is sometimes very very slow, that
> >might result in the checkpoint overrunning its time budget - but SO
> >WHAT?
>
> Checkpoints provide a boundary on recovery time. That is their only
> purpose. You can a
On Thu, Jul 18, 2013 at 11:41 AM, Greg Smith wrote:
> On 7/18/13 11:04 AM, Robert Haas wrote:
>> On a system where fsync is sometimes very very slow, that
>> might result in the checkpoint overrunning its time budget - but SO
>> WHAT?
>
> Checkpoints provide a boundary on recovery time. That is t
Robert Haas escribió:
> On Thu, Jul 18, 2013 at 10:34 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> 1. snapshot-error-v1.patch introduces a new special snapshot, called
> >> SnapshotError. In the cases where we set SnapshotNow as a sort of
> >> default snapshot, this patch changes the code to
On 7/18/13 11:04 AM, Robert Haas wrote:
On a system where fsync is sometimes very very slow, that
might result in the checkpoint overrunning its time budget - but SO
WHAT?
Checkpoints provide a boundary on recovery time. That is their only
purpose. You can always do better by postponing them
Please stop all this discussion of patents in this area. Bringing up a
US patents here makes US list members more likely to be treated as
willful infringers of that patent:
http://www.ipwatchdog.com/patent/advanced-patent/willful-patent-infringement/
if the PostgreSQL code duplicates that meth
On Sun, Jul 14, 2013 at 3:13 PM, Greg Smith wrote:
> Accordingly, the current behavior--no delay--is already the best possible
> throughput. If you apply a write timing change and it seems to increase
> TPS, that's almost certainly because it executed less checkpoint writes.
> It's not a fair com
On Thu, Jul 18, 2013 at 10:34 AM, Tom Lane wrote:
> Robert Haas writes:
>> 1. snapshot-error-v1.patch introduces a new special snapshot, called
>> SnapshotError. In the cases where we set SnapshotNow as a sort of
>> default snapshot, this patch changes the code to use SnapshotError
>> instead.
Robert Haas writes:
> 1. snapshot-error-v1.patch introduces a new special snapshot, called
> SnapshotError. In the cases where we set SnapshotNow as a sort of
> default snapshot, this patch changes the code to use SnapshotError
> instead. This affects scan->xs_snapshot in genam.c and
> estate->e
Hello again Tatsuo,
For your information, included is the patch against git master head to
implement the lag in a way what I proposed. With the patch, I get more
consistent number on Linux (and Mac OS X).
I must disagree with your proposal: At least, it does not provide the
information I wan
Robert Haas writes:
> On Wed, Jul 17, 2013 at 2:03 PM, Gurjeet Singh wrote:
>> Agreed that bushy/right-deep trees are a remote corner case, but we are
>> addressing a remote corner case in the first place (insanely long AND lists)
>> and why not handle another remote corner case right now if it d
On 07/18/2013 08:59 AM, Merlin Moncure wrote:
On Thu, Jul 18, 2013 at 7:57 AM, Merlin Moncure wrote:
One thing that could solve a lot of issues would be to disable
readline when inside a dollar quote etc.
actually, that's dumb (pre-coffee).
Yeah, but what would be useful would be a way to
On Wed, Jul 17, 2013 at 2:03 PM, Gurjeet Singh wrote:
> In v6 of the patch, I have deferred the 'pending' list initialization to
> until we actually hit a candidate right-branch. So in the common case the
> pending list will never be populated, and if we find a bushy or right-deep
> tree (for som
On Thu, Jul 18, 2013 at 7:57 AM, Merlin Moncure wrote:
> One thing that could solve a lot of issues would be to disable
> readline when inside a dollar quote etc.
actually, that's dumb (pre-coffee).
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
On Wed, Jul 17, 2013 at 6:30 PM, Dimitri Fontaine
wrote:
> Josh Berkus writes:
>> So, an even more practical workaround (I've been using cat | psql), but
>> still a mysterious issue.
>
> As a workaround you might try \e with EDITOR=emacs or some of the other
> solutions you've been pasting, maybe
There seems to be a consensus that we should try to get rid of
SnapshotNow entirely now that we have MVCC catalog scans, so I'm
attaching two patches that together come close to achieving that goal:
1. snapshot-error-v1.patch introduces a new special snapshot, called
SnapshotError. In the cases w
Hello Robins,
Thanks Fabien. This was a wrong attachment to the email.
This patch works for me (applied, tested).
However, some remarks:
seq4: should it check something? How do you know that OWNED BY did
anything?
regress_role_seq2: shoult check that the sequence owner is the table
owne
On Wednesday, July 17, 2013 6:08 PM Ants Aasma wrote:
> On Wed, Jul 17, 2013 at 2:54 PM, Amit Kapila
> wrote:
> > I think Oracle also use similar concept for making writes efficient,
> and
> > they have patent also for this technology which you can find at below
> link:
> >
> http://www.google.com
On Thursday, July 18, 2013 12:38 AM Josh Berkus wrote:
> On 07/17/2013 12:01 PM, Alvaro Herrera wrote:
> > Both of these seem like they would make troubleshooters' lives more
> > difficult. I think we should just parse the auto file automatically
> > after parsing postgresql.conf, without requirin
Hmm. I'm sorry to find that this patch is already marked as
'Return with Feedback' on the CF page around the same time when
the preveous review comment has sent. Is it somewhat crossing?
Anyway, I'll take a rain check for this.
> I have simply merged the two regtests separately into two
> origina
Thank you for the worthwhile additions.
At Tue, 16 Jul 2013 16:04:43 +0900, Satoshi Nagayasu wrote in
<51e4f08b.3030...@uptime.jp>
> > | postgres=# select * from pg_freespace_with_vminfo('t'::regclass) limit
> > | 10;
..
> I think we can simply add is_all_viible column to the existing
> pg_frees
Hello Tatsuo
I think current measurement method will give enough confusion if it's
not provided with detailed explanation. Could you please provide doc
updatation?
Please find a v17 proposition with an updated and extended documentation,
focussed on clarifying the lag measure and its implic
Fabien,
> Hello again Tatsuo,
>
>> For your information, included is the patch against git master head to
>> implement the lag in a way what I proposed. With the patch, I get more
>> consistent number on Linux (and Mac OS X).
>
> I must disagree with your proposal: At least, it does not provide
Hello Greg,
The lag computation was not the interesting part of this feature to me. As I
said before, I considered it more of a debugging level thing than a number
people would analyze as much as you did. I understand why you don't like it
though. If the reference time was moved forward to
On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote:
> It's always annoyed me that pgindent insists on adjusting vertical
> whitespace around #else and related commands. This has, for example,
> rendered src/include/storage/barrier.h nigh illegible: you get things
> like
>
> /*
> * lwsync o
Hello Tatsuo,
I think I'm starting to understand what's going on. Suppose there are
n transactions be issued by pgbench and it decides each schedule d(0),
d(1)... d(n). Actually the schedule d(i) (which is stored in
st->until) is decided by the following code:
int64 wait = (in
90 matches
Mail list logo
