Hi,
I've been working on new pgstattuple function to allow
block sampling [1] in order to reduce block reads while
scanning a table. A PoC patch is attached.
[1] Re: [RFC] pgstattuple/pgstatindex enhancement
http://www.postgresql.org/message-id/ca+tgmoaxjhgz2c4ayfbr9muuvnhgwu4co-cthqpzrwwdtam...
On 07/23/2013 12:52 PM, Tom Lane wrote:
> Craig Ringer writes:
>>> Showing that I'm still very much learning this area myself, a bit more
>>> looking around found:
>>> http://www.postgresql.org/docs/current/static/querytree.html
>>> which makes it clear that the range table for the query will cont
2013/7/23 Tom Lane :
> Robert Haas writes:
>> On Sun, Jul 21, 2013 at 12:47 AM, Pavel Stehule
>> wrote:
>>> I propose a few new commands
>>>
>>> \dts [N|size] ... show N largest tables | show tables larger than size
>>> ordered by size
>>> \dis [N|size] ... show N largest indexes | show indexes
Andrew Gierth writes:
> I must admit to finding all of this criticism of unread code a bit
> bizarre.
If you yourself are still finding bugs in the code as of this afternoon,
onlookers could be forgiven for doubting that the code is quite as
readable or ready to commit as all that.
Robert Haas writes:
> On Sun, Jul 21, 2013 at 12:47 AM, Pavel Stehule
> wrote:
>> I propose a few new commands
>>
>> \dts [N|size] ... show N largest tables | show tables larger than size
>> ordered by size
>> \dis [N|size] ... show N largest indexes | show indexes larger than
>> size ordered b
> On Tuesday, July 23, 2013 5:26 AM Tom Lane wrote:
> Josh Berkus writes:
> > Christophe just discovered something with include files which is
> going
> > to cause issues with ALTER SYSTEM SET.
>
> > So, take as a hypothetical that you use the default postgresql.conf
> > file, which sets shared_b
Craig Ringer writes:
>> Showing that I'm still very much learning this area myself, a bit more
>> looking around found:
>> http://www.postgresql.org/docs/current/static/querytree.html
>> which makes it clear that the range table for the query will contain
>> what you want. I suspect you'll need to
> (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.
>
True that.
I spent some time on it, but couldn't come up with anything useful.
Mike's extensive testing seems good enough for me, thoug
On Mon, Jul 22, 2013 at 09:52:14PM +0200, Karol Trzcionka wrote:
> I've noticed problem with "UPDATE ... FROM" statement. Fix in new version.
> Regards,
> Karol
What problem or problems did you notice, and what did you change to
fix them?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone:
2013/7/23 Pavel Stehule :
> 2013/7/22 Dimitri Fontaine :
>> Pavel Stehule writes:
SELECT * from top5();
>>
>> $ TABLE top5; -- add a view on top of the SRF
>>
>>> you cannot use parameters - then I have to have prepared files like
>>> top10, top20, ... what is not too friendly
>>
>> The SR
2013/7/22 Dimitri Fontaine :
> Pavel Stehule writes:
>>> SELECT * from top5();
>
> $ TABLE top5; -- add a view on top of the SRF
>
>> you cannot use parameters - then I have to have prepared files like
>> top10, top20, ... what is not too friendly
>
> The SRF could be using custom GUCs so that
Hello,
While understanding the effect of maintenance_work_mem on time taken
by CREATE INDEX, I observed that for the values of
maintenance_work_mem less than the value for which an internal sort is
performed, the time taken by CREATE INDEX increases as
maintenance_work_increases.
My guess is that
2013/7/23 Tom Lane :
> Jeff Janes writes:
>> Is looking for the biggest tables a common enough thing that it should
>> be available to everyone, without needing custom customization?
>
> I don't really think so. It's surely not much harder than
>
> select relname, pg_relation_size(oid) fr
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 Alv
>> I agree with Robert. My tip is this: when you're in a hole, the first thing
>> to do is to stop digging.
>
> I don't think that Pavel believes himself to be in a hole.
>
> After setting up my .psqlrc file as I normally do, I could do this:
>
> :rtsize limit 10;
>
> But it doesn't have the 'MB' f
On 07/23/2013 11:41 AM, Craig Ringer wrote:
> On 07/23/2013 11:24 AM, Craig Ringer wrote:
>> On 07/21/2013 10:42 PM, Миша Тюрин wrote:
>>>
>>> hi, list, again. the next proposal into auto explain. one would be happy if
>>> could set list of target tables and indexes. sometimes it is very hard to
Recently I've been dismissing a lot of suggested changes to checkpoint
fsync timing without suggesting an alternative. I have a simple one in
mind that captures the biggest problem I see: that the number of
backend and checkpoint writes to a file are not connected at all.
We know that a 1GB
On 07/23/2013 11:24 AM, Craig Ringer wrote:
> On 07/21/2013 10:42 PM, Миша Тюрин wrote:
>>
>> hi, list, again. the next proposal into auto explain. one would be happy if
>> could set list of target tables and indexes. sometimes it is very hard to
>> detect who is using your indexes. but turn tota
Noah Misch wrote:
> I meant to ask whether, instead of reverting the accidental behavior change,
> we should do something like leave the behavior and change the documentation
> instead. I personally vote "no", but that alternative seemed credible enough
> to justify mentioning it. Something more
On 07/21/2013 10:42 PM, Миша Тюрин wrote:
>
> hi, list, again. the next proposal into auto explain. one would be happy if
> could set list of target tables and indexes. sometimes it is very hard to
> detect who is using your indexes. but turn total logging on under thousands
> transactions per
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 :-(
Yeah, I only did a first pass over that patch and was expecting you
On 7/22/13 4:52 AM, KONDO Mitsumasa wrote:
The writeback source code which I indicated part of writeback is almost
same as community kernel (2.6.32.61). I also read linux kernel 3.9.7,
but it is almost same this part.
The main source code difference comes from going back to the RedHat 5
kernel
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 :-(
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-ha
I wrote:
> After some reflection I think that the best fix is to redefine
> AcquireRewriteLocks' processing of dropped columns so that it puts an
> actual null pointer, not a consed-up Const, into the joinaliasvars list
> item.
Here's a complete patch along that line. Possibly worthy of note is
t
After pushes from a few people, the remaining submissions are now
waiting for commit. I updated each of those to have the latest info in
the CF app, and tried to identify what committers have already looked at
them.
Access to calls stack from GET DIAGNOSTICS statement: ?
Add more regression
Noah Misch writes:
> On Sun, Jul 21, 2013 at 12:40:38PM -0400, Tom Lane wrote:
>> Hmm ... good point. The other plan I'd been considering was to add
>> explicit tracking inside spi.c of all tuple tables created within the
>> current procedure, and then have AtEOSubXact_SPI flush any that were
>>
On Sun, Jul 21, 2013 at 12:40:38PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > Reasonable enough. Code that does use subtransactions will need to be more
> > careful than before to manually free tuple tables in the non-error case.
> > Failure to do so has been creating a leak that lasts until
On 6/26/13 9:34 PM, Peter Eisentraut wrote:
Still wondering whether to use a A,B,C-based output
format per Tom's comment.
Wouldn't it also be helpful to remove "The points used in the output are
not necessarily the points used on input" by making that not true?
There are three obvious ways y
Ok, since Atri posted our work-so-far and there's not been much
comment, I'll outline here my proposed plan of attack.
Rather than, as in the WIP patch, using the agg finalfn to validate
the split between normal args and ORDER BY args, I propose this:
Firstly, as in the WIP patch,
func(a) with
On Sun, Jul 21, 2013 at 01:47:00PM -0700, Josh Berkus wrote:
> On 07/21/2013 11:30 AM, Josh Berkus wrote:
> >> Attached patch just restores the old behavior. Would it be worth
> >> preserving
> >> the ability to fix an index consistency problem with a REINDEX independent
> >> from related heap co
On 7/3/13 7:25 PM, Bruce Momjian wrote:
The extrapolation of Josh's approach is that committers
have to do work that the community wants to maintain their commit
rights, but their commit rights are helping the community, so why would
people care if you take them away --- you only hurt the communi
On 2013-07-23 00:01:50 +0200, Andres Freund wrote:
> On 2013-07-17 10:11:28 -0400, Tom Lane wrote:
> > Kevin Grittner writes:
> > > Add support for REFRESH MATERIALIZED VIEW CONCURRENTLY.
> >
> > The buildfarm members that use -DCLOBBER_CACHE_ALWAYS say this patch
> > is broken.
>
> Jagarundi st
Josh Berkus writes:
> Christophe just discovered something with include files which is going
> to cause issues with ALTER SYSTEM SET.
> So, take as a hypothetical that you use the default postgresql.conf
> file, which sets shared_buffers = 32MB.
> Instead of editing this file, you do ALTER SYSTE
> Very minor update with V19 here, to reflect Alvaro's comments. The
> tricky part now reads like this:
>
> High rate limit schedule lag values, that is lag values that are large
> compared to the actual transaction latency, indicate that something is
> amiss in the throttling process. High sche
On 07/22/2013 04:26 PM, Jeff Janes wrote:
On Mon, Jul 22, 2013 at 12:40 PM, Andrew Dunstan wrote:
On 07/22/2013 03:11 PM, Pavel Stehule wrote:
2013/7/22 Robert Haas :
Rather than just continuing to add more imposible-to-remember syntax,
we really need a better design here.
do you have any
Jeff Janes writes:
> Is looking for the biggest tables a common enough thing that it should
> be available to everyone, without needing custom customization?
I don't really think so. It's surely not much harder than
select relname, pg_relation_size(oid) from pg_class order by 2 desc;
M
All,
Christophe just discovered something with include files which is going
to cause issues with ALTER SYSTEM SET.
So, take as a hypothetical that you use the default postgresql.conf
file, which sets shared_buffers = 32MB.
Instead of editing this file, you do ALTER SYSTEM SET shared_buffers =
'1
Andres Freund writes:
> On 2013-07-22 15:55:46 -0400, Robert Haas wrote:
>> And why is that?
> The comment above tells: "while the lower half is the XOR of tv_sec and
> tv_usec."
Yeah, the code doesn't match the comment; this mistake seems to be
aboriginal.
> I don't think it really matters. th
Andres Freund writes:
> On 2013-07-22 17:04:06 -0400, Alvaro Herrera wrote:
>> One way to attack this would be registering dependencies of a new kind
>> on functions used by index expressions. Then CREATE OR REPLACE function
>> could reject alteration for such functions. I don't know if we care
On 2013-07-22 19:09:13 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-17 10:11:28 -0400, Tom Lane wrote:
> >> The buildfarm members that use -DCLOBBER_CACHE_ALWAYS say this patch
> >> is broken.
>
> > Jagarundi still tells that story.
>
> Uh, no. Jagarundi was perfectly happy for
"David E. Wheeler" writes:
> But I do wonder if the comma should be allowed for fractional seconds,
> since the spec says it is preferred (and often used in Javaland, I'm
> told). As in "14:30:50,232". Thoughts?
Does that create any ambiguities against formats we already support?
I'm worried abou
On 6/24/13 12:57 PM, Josh Berkus wrote:
Maciej is correct that this policy also belongs on the "how to submit a
patch" wiki page. I will remedy that.
I just reviewed and heavily updated the new section you added to
https://wiki.postgresql.org/wiki/Submitting_a_Patch That included the
idea t
Andres Freund writes:
> On 2013-07-17 10:11:28 -0400, Tom Lane wrote:
>> The buildfarm members that use -DCLOBBER_CACHE_ALWAYS say this patch
>> is broken.
> Jagarundi still tells that story.
Uh, no. Jagarundi was perfectly happy for several build cycles after
I committed 405a468. The buildfar
On Mon, Jul 22, 2013 at 03:55:33PM -0700, David Fetter wrote:
> On Mon, Jul 22, 2013 at 02:44:59PM -0700, Dimitri Fontaine wrote:
> > Pavel Stehule writes:
> > >> SELECT * from top5();
> >
> > $ TABLE top5; -- add a view on top of the SRF
> >
> > > you cannot use parameters - then I have to h
On Mon, Jul 22, 2013 at 02:44:59PM -0700, Dimitri Fontaine wrote:
> Pavel Stehule writes:
> >> SELECT * from top5();
>
> $ TABLE top5; -- add a view on top of the SRF
>
> > you cannot use parameters - then I have to have prepared files like
> > top10, top20, ... what is not too friendly
>
>
On Mon, Jul 22, 2013 at 6:01 PM, Andres Freund wrote:
> On 2013-07-17 10:11:28 -0400, Tom Lane wrote:
>> Kevin Grittner writes:
>> > Add support for REFRESH MATERIALIZED VIEW CONCURRENTLY.
>>
>> The buildfarm members that use -DCLOBBER_CACHE_ALWAYS say this patch
>> is broken.
>
> Jagarundi still
On Sun, Jul 21, 2013 at 4:44 AM, Ants Aasma wrote:
> On Jul 21, 2013 4:06 AM, "Noah Misch" wrote:
>> If these hooks will need to apply to a larger operation, I
>> think that mandates a different means to reliably expose the before/after
>> object states.
>
> I haven't checked the code to see how
On 2013-07-17 10:11:28 -0400, Tom Lane wrote:
> Kevin Grittner writes:
> > Add support for REFRESH MATERIALIZED VIEW CONCURRENTLY.
>
> The buildfarm members that use -DCLOBBER_CACHE_ALWAYS say this patch
> is broken.
Jagarundi still tells that story. At least something like the following
patch s
Pavel Stehule writes:
>> SELECT * from top5();
$ TABLE top5; -- add a view on top of the SRF
> you cannot use parameters - then I have to have prepared files like
> top10, top20, ... what is not too friendly
The SRF could be using custom GUCs so that you can parametrize it, or
just even clas
Hackers,
According to [Wikipedia](https://en.wikipedia.org/wiki/ISO_8601#Times):
> Decimal fractions may also be added to any of the three time elements. A
> decimal mark, either a comma or a dot (without any preference as stated in
> resolution 10 of the 22nd General Conference CGPM in 2003,[1
On 2013-07-22 17:04:06 -0400, Alvaro Herrera wrote:
> Pavan Deolasee escribió:
> > Hello,
> >
> > While doing some tests, I observed that expression indexes can malfunction
> > if the underlying expression changes.
>
> [...]
>
> > Perhaps this is a known behaviour/limitation, but I could not fin
On Mon, Jul 22, 2013 at 6:04 PM, Alvaro Herrera
wrote:
> Pavan Deolasee escribió:
>> Hello,
>>
>> While doing some tests, I observed that expression indexes can malfunction
>> if the underlying expression changes.
>
> [...]
>
>> Perhaps this is a known behaviour/limitation, but I could not find th
Pavan Deolasee escribió:
> Hello,
>
> While doing some tests, I observed that expression indexes can malfunction
> if the underlying expression changes.
[...]
> Perhaps this is a known behaviour/limitation, but I could not find that in
> the documentation. But I wonder if it makes sense to check
On 7/20/13 10:08 AM, Kohei KaiGai wrote:
With that change to expand_targetlist(), the change to getrelid() may
be unnecessary, and then also the new rowsec_relid field in
RangeTblEntry may not be needed.
Hmm. I didn't have this idea. It seems to me fair enough and kills
necessity to enhance Ra
On Mon, Jul 22, 2013 at 12:40 PM, Andrew Dunstan wrote:
>
> On 07/22/2013 03:11 PM, Pavel Stehule wrote:
>>
>> 2013/7/22 Robert Haas :
>>
>>
>>> Rather than just continuing to add more imposible-to-remember syntax,
>>> we really need a better design here.
>>
>> do you have any tip?
>>
>>
>>
>
> I
On Fri, Jul 19, 2013 at 1:20 PM, Alvaro Herrera
wrote:
>> 4. If we use GetActiveSnapshot, all the comments about about a fresh
>> MVCC snapshot still apply. However, the snapshot in question could be
>> even more stale, especially in repeatable read or serializable mode.
>> However, this might be
On 7/22/13 2:57 PM, Andres Freund wrote:
* I'd be very surprised if this doesn't make WAL replay of update heavy
workloads slower by at least factor of 2.
I was thinking about what a benchmark of WAL replay would look like last
year. I don't think that data is captured very well yet, and i
Peter Eisentraut wrote:
> I would suggest that these changes be undone, except that the old
> "SELECT FOR ..." be replaced by a dynamic string that reverse-parses the
> LockingClause to provide the actual clause that was used.
Here's a patch for this.
--
Álvaro Herrerahttp://www
On 7/22/13 7:21 AM, Andres Freund wrote:
> Would somebody object to making the rmgr's invo value #defines like:
I'm suspicious of enums that are assigned specific values. Enums should
stand by themselves, they shouldn't be a symbolic layer on top of some
other numbering or bit-fiddling scheme.
On 2013-07-22 15:55:46 -0400, Robert Haas wrote:
> On Mon, Jul 22, 2013 at 6:45 AM, didier wrote:
> > Hi
> >
> > in void
> > BootStrapXLOG(void)
> >
> > * to seed it other than the system clock value...) The upper half of
> > the
> > * uint64 value is just the tv_sec part, while th
On Mon, Jul 22, 2013 at 6:45 AM, didier wrote:
> Hi
>
> in void
> BootStrapXLOG(void)
>
> * to seed it other than the system clock value...) The upper half of
> the
> * uint64 value is just the tv_sec part, while the lower half is the
> XOR
> * of tv_sec and tv_usec. This
I've noticed problem with "UPDATE ... FROM" statement. Fix in new version.
Regards,
Karol
diff --git a/doc/src/sgml/ref/update.sgml b/doc/src/sgml/ref/update.sgml
index 90b9208..eba35f0 100644
--- a/doc/src/sgml/ref/update.sgml
+++ b/doc/src/sgml/ref/update.sgml
@@ -194,12 +194,27 @@ UPDATE [ ONLY
On Mon, Jul 22, 2013 at 3:16 PM, Robert Haas wrote:
> I think we have consensus to back-patch the other API changes as well.
> I'll work up a patch for that.
Pushed that as well.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hac
On 07/22/2013 03:11 PM, Pavel Stehule wrote:
2013/7/22 Robert Haas :
Rather than just continuing to add more imposible-to-remember syntax,
we really need a better design here.
do you have any tip?
I agree with Robert. My tip is this: when you're in a hole, the first
thing to do is to st
In
http://www.postgresql.org/message-id/cak_s-g3-fwveer1c0idvtz0745-7ryifi8whbzcnmsn+hwc...@mail.gmail.com
it's pointed out that commit 2ffa740b was a few bricks shy of a load,
because it failed to cope with the possibility of a joinaliasvars item
containing an implicit coercion. That's not too ha
2013/7/22 Merlin Moncure :
> On Mon, Jul 22, 2013 at 2:03 PM, Robert Haas wrote:
>> On Sun, Jul 21, 2013 at 12:47 AM, Pavel Stehule
>> wrote:
>>> Hello all
>>>
>>> I very often use a little bit adjusted psql system queries to
>>> detection TOP N sized tables. I am thinking so it can be useful fo
Dimitri,
On 07/22/2013 08:44 PM, Dimitri Fontaine wrote:
> That's the trade-off we currently need to make to be able to ship with
> the current security protections we're talking about.
Anything wrong with shipping postgis-1.5.so and postgis-2.0.so, as I we
for Debian?
> Ok, here's the full work
Tom Lane said:
> I haven't read this patch, but that comment scares the heck out of me.
> Even if the patch isn't broken today, it will be tomorrow, if it's
> making random changes like that in data structure semantics.
> Also, if you're confused, so will be everybody else who has to deal with
> th
Greg Smith escribió:
> On 7/22/13 12:58 PM, Amit kapila wrote:
> >As per discussion, updated patch contains following changes:
> >1. Regression tests for Alter System are removed
> >2. Parsed the auto file automatically after parsing postgresql.conf
> >3. Removed addition of include directive in po
On Mon, Jul 22, 2013 at 3:13 PM, Merlin Moncure wrote:
> On Mon, Jul 22, 2013 at 2:03 PM, Robert Haas wrote:
>> On Sun, Jul 21, 2013 at 12:47 AM, Pavel Stehule
>> wrote:
>>> Hello all
>>>
>>> I very often use a little bit adjusted psql system queries to
>>> detection TOP N sized tables. I am th
On Sat, Jul 20, 2013 at 12:39 AM, Alvaro Herrera
wrote:
>> I don't have a problem with getting rid of those, it's easy enough to
>> register them inside the worker and it's safe since we start with
>> blocked signals. I seem to remember some discussion about why they were
>> added but I can't find
On Mon, Jul 22, 2013 at 2:03 PM, Robert Haas wrote:
> On Sun, Jul 21, 2013 at 12:47 AM, Pavel Stehule
> wrote:
>> Hello all
>>
>> I very often use a little bit adjusted psql system queries to
>> detection TOP N sized tables. I am thinking so it can be useful for
>> all users
>>
>> I propose a fe
2013/7/22 Robert Haas :
> On Sun, Jul 21, 2013 at 12:47 AM, Pavel Stehule
> wrote:
>> Hello all
>>
>> I very often use a little bit adjusted psql system queries to
>> detection TOP N sized tables. I am thinking so it can be useful for
>> all users
>>
>> I propose a few new commands
>>
>> \dts [N|
On 7/22/13 12:58 PM, Amit kapila wrote:
As per discussion, updated patch contains following changes:
1. Regression tests for Alter System are removed
2. Parsed the auto file automatically after parsing postgresql.conf
3. Removed addition of include directive in postgresql.conf
4. Removed error ha
On Sun, Jul 21, 2013 at 12:47 AM, Pavel Stehule wrote:
> Hello all
>
> I very often use a little bit adjusted psql system queries to
> detection TOP N sized tables. I am thinking so it can be useful for
> all users
>
> I propose a few new commands
>
> \dts [N|size] ... show N largest tables | show
On 2013-07-19 10:40:01 +0530, Hari Babu wrote:
>
> 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.
> >>
Markus Wanner writes:
- per-installation (not even per-cluster) DSO availability
>
> Not sure what the issue is, here, but I agree that should be possible.
For any extension where the new package version is shipping the same .so
file name, you can only have one module on the whole system f
The v3 patch applies perfectly here now. Attached is a spreadsheet with
test results from two platforms, a Mac laptop and a Linux server. I
used systems with high disk speed because that seemed like a worst case
for this improvement. The actual improvement for shrinking WAL should
be even be
Hello,
While doing some tests, I observed that expression indexes can malfunction
if the underlying expression changes. For example, say I define a function
foo() as:
CREATE OR REPLACE FUNCTION foo(a integer) RETURNS integer AS $$
BEGIN
RETURN $1 + 1;
END;
$$ LANGUAGE plpgsql IMMUTABLE;
I then
On Fri, Jul 19, 2013 at 1:46 PM, David Fetter wrote:
>> This functionality was actually present in the original submission
>> for foreign tables. I ripped it out before commit because I didn't
>> think all of the interactions with other commands had been
>> adequately considered. But I think the
On Mon, Jul 22, 2013 at 01:49:39PM -0400, Greg Smith wrote:
> Very minor update with V19 here, to reflect Alvaro's comments. The
> tricky part now reads like this:
>
> High rate limit schedule lag values,
"High values of the rate limit schedule lag measurement?"
> that is lag values that are la
On Fri, Jun 14, 2013 at 6:51 PM, Andres Freund wrote:
> The git tree is at:
> git://git.postgresql.org/git/users/andresfreund/postgres.git branch
> xlog-decoding-rebasing-cf4
> http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/xlog-decoding-rebasing-cf4
>
Very minor update with V19 here, to reflect Alvaro's comments. The
tricky part now reads like this:
High rate limit schedule lag values, that is lag values that are large
compared to the actual transaction latency, indicate that something is
amiss in the throttling process. High schedule lag
On 07/22/2013 12:49 PM, Greg Stark wrote:
On Mon, Jul 22, 2013 at 12:50 PM, Peter Eisentraut wrote:
I think part of the problem is that we call strcoll for each comparison,
instead of doing strxfrm once for each datum and then just strcmp for
each comparison. That is effectively equivalent to
Greg Stark said:
> So the more I look at this patch the fewer things I want to change in
> it. I've several times thought I should make an improvement and then
> realized I was really just making unnecessary tweaks that didn't
> really make much difference.
It's almost as though we actually though
Hello Alvaro,
Thanks. I didn't look at the code, but while trying to read the docs:
+
+ High rate limit schedule lag values, that is values not small with
+ respect to the actual transaction latency, indicate that something is
+ amiss in the throttling process
Hello Greg,
Thanks for the improvement!
I have a small reservation about "finish/end time schedule" in the second
paragraph, or maybe there is something that I do not understand. There is
no schedule for finishing anything, only start times are scheduled, so I
wish the text could avoid sugg
Greg Smith wrote:
Thanks. I didn't look at the code, but while trying to read the docs:
> +
> + High rate limit schedule lag values, that is values not small with
> + respect to the actual transaction latency, indicate that something
> is
> + amiss in the throttl
On Mon, Jul 22, 2013 at 12:50 PM, Peter Eisentraut wrote:
> I think part of the problem is that we call strcoll for each comparison,
> instead of doing strxfrm once for each datum and then just strcmp for
> each comparison. That is effectively equivalent to what the proposal
> implements.
Fwiw I
On Mon, Jul 22, 2013 at 4:42 PM, Tom Lane wrote:
> I haven't read this patch, but that comment scares the heck out of me.
> Even if the patch isn't broken today, it will be tomorrow, if it's
> making random changes like that in data structure semantics.
It's not making random changes. It's just t
Attached is an update that I think sorts out all of the documentation
concerns. I broke this section into paragraphs now that it's getting so
long too.
The only code change is that this now labels the controversial lag here
"average rate limit schedule lag". That way if someone wants to
int
So the more I look at this patch the fewer things I want to change in
it. I've several times thought I should make an improvement and then
realized I was really just making unnecessary tweaks that didn't
really make much difference.
It seems a shame that the node has to call the function and get b
On Tue, Jul 16, 2013 at 9:00 AM, Robert Haas wrote:
> On Sun, Jul 7, 2013 at 4:34 PM, Andres Freund wrote:
>> On 2013-07-07 15:43:17 -0400, Tom Lane wrote:
>>> Andres Freund writes:
>>> > 3b) Add catcache 'filter' that ensures the cache stays unique and use
>>> > that for the mapping
>>>
>>>
Greg Stark writes:
> I do find the logic and variable names a bit confusing so I'm tempted
> to add some comments based on my initial confusion. And I'm tempted to
> add an ordinalityAttNum field to the executor node so we don't need to
> make these odd "scanslot means this unless we have ordinali
Le lundi 22 juillet 2013 09:39:50, Craig Ringer a écrit :
> On 07/22/2013 03:30 PM, Миша Тюрин wrote:
> >
> > i tell about wal_level is higher than MINIMAL
>
> OK, so you want to be able to force O_DIRECT for wal_level = archive ?
>
> I guess that makes sense if you expect the archive_command to
On Fri, Jul 19, 2013 at 2:20 PM, Samrat Revagade
wrote:
> for example:
> if i want to configure 2 servers then it will add 6 lines,for 3 -9, for 4-12
> setting's for particular server will be:
>
> considering the way of setting value to conf parameters : guc . value
>
> standby_name.'AAA'
> sync
On 2013-07-22 08:53:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Would somebody object to making the rmgr's invo value #defines like:
> > into enums?
>
> I think that will create more problems than it fixes. For one thing,
> the same field is used to store values that would need to be m
Andres Freund writes:
> Would somebody object to making the rmgr's invo value #defines like:
> into enums?
I think that will create more problems than it fixes. For one thing,
the same field is used to store values that would need to be multiple
independent enum types; and we also store addition
On Sun, Jul 21, 2013 at 11:30:54AM -0700, Josh Berkus wrote:
> Noah,
>
> > Attached patch just restores the old behavior. Would it be worth preserving
> > the ability to fix an index consistency problem with a REINDEX independent
> > from related heap consistency problems such as duplicate keys?
On 7/22/13 3:54 AM, Craig Ringer wrote:
> It might be worth looking at gcc's strcoll() implementation. See if it
> performs better when you use the latest gcc, and if not try to improve
> gcc's strcoll() .
I think part of the problem is that we call strcoll for each comparison,
instead of doing st
1 - 100 of 113 matches
Mail list logo
