On Wed, May 25, 2011 at 9:41 AM, Tom Lane wrote:
> Yeah, I had been thinking about the latter point. We could be
> conservative and just keep the reported tuple density the same (ie,
> update relpages to the new correct value, while setting reltuples so
> that the density ratio doesn't change).
On Wed, May 25, 2011 at 10:05 PM, Greg Stark wrote:
>> updated_density = old_density + (new_density - old_density) * reliability
>> new_reltuples = updated_density * new_relpages
>
> This amounts to assuming that the pages observed in the vacuum have
> the density observed and the pages that weren
On Thu, May 26, 2011 at 1:18 PM, Robert Haas wrote:
>> The replay of the WAL record for A doesn't rely on the content of chunk 1
>> which B modified. So I don't think that "partial page writes" has such
>> a problem.
>> No?
>
> Sorry. WAL records today DO rely on the prior state of the page. If
On Wed, May 25, 2011 at 10:09 PM, Fujii Masao wrote:
> On Wed, May 25, 2011 at 9:34 PM, Robert Haas wrote:
>> On Tue, May 24, 2011 at 10:52 PM, Jeff Davis wrote:
>>> On Tue, 2011-05-24 at 16:34 -0400, Robert Haas wrote:
As I think about it a bit more, we'd
need to XLOG not only the par
On Wed, May 25, 2011 at 11:51 PM, Pavan Deolasee
wrote:
>> Agreed. The only thing I'm trying to do further is to avoid the need
>> for a reshuffle when the special LSN storage is reclaimed.
>
> Ah ok. That was never clear from your initial emails or may be I
> mis-read.
Sorry, I must not have ex
On Wed, May 25, 2011 at 11:39 PM, Robert Haas wrote:
> On Wed, May 25, 2011 at 1:43 PM, Pavan Deolasee
> Now, there
>> is no way you can store is after the line pointer array without moving
>> the live tuple somewhere else.
>
> So far I agree. But don't we always defragment immediately after
> pr
> Dan Ports wrote:
> On Tue, May 24, 2011 at 04:18:37AM -0500, Kevin Grittner wrote:
>> These proofs show that there is no legitimate cycle which could
>> cause an anomaly which the move from row-based to tuple-based
>> logic will miss. They don't prove that the change will generate
>> all the s
On Wed, May 25, 2011 at 9:34 PM, Robert Haas wrote:
> On Tue, May 24, 2011 at 10:52 PM, Jeff Davis wrote:
>> On Tue, 2011-05-24 at 16:34 -0400, Robert Haas wrote:
>>> As I think about it a bit more, we'd
>>> need to XLOG not only the parts of the page we actually modifying, but
>>> any that the W
On Wed, May 25, 2011 at 8:37 PM, Michael Nolan wrote:
> On Wed, May 25, 2011 at 11:18 AM, Robert Haas wrote:
>>
>> I basically agree. There have been several recent discussions of this
>> topic on both -hackers and -performance; it is likely that the TODO
>> needs to be updated with some more re
On Wed, May 25, 2011 at 11:18 AM, Robert Haas wrote:
>
> I basically agree. There have been several recent discussions of this
> topic on both -hackers and -performance; it is likely that the TODO
> needs to be updated with some more recent links.
>
Anything to help the NKOTB to get up to speed
On Tue, May 24, 2011 at 1:34 PM, Robert Haas wrote:
> 1. Heikki suggested that instead of doing full page writes, we might
> try to write only the parts of the page that have changed. For
> example, if we had 16 bits to play with in the page header (which we
> don't), then we could imagine the pa
On Wed, May 25, 2011 at 3:07 PM, Peter Eisentraut wrote:
> On ons, 2011-04-27 at 18:14 -0400, Noah Misch wrote:
>> Enthusiastic +1 for this concept. There's at least one rough edge: it fails
>> if
>> you have another postmaster running on port 5432.
>
> This has now been addressed: pg_upgrade ac
On Wed, May 25, 2011 at 5:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, May 25, 2011 at 1:04 PM, Tom Lane wrote:
>>> Because the problem is not specific to TOAST tables. As things
>>> currently stand, we will accept the word of an ANALYZE as gospel even if
>>> it scanned 1% of the tab
I wrote:
> Heikki Linnakangas writes:
>> BTW, i just stumbled into this:
>> postgres=# explain verbose SELECT CASE now() WHEN (29+random()::int4)
>> THEN 'foo' ELSE 'bar' END;
>> ERROR: unexpected CASE WHEN clause: 326
>> Looks like ruleutils.c is also not prepared for the case that the
>> im
> I thought the problem was that they upgraded the OS and now the encoding
> names changed, though they behaved the same. Is that now what is
> happening? Can they supply the values with different cases?
>
In my case I never touched the locale. It was set by the OS. I presume
this is true for m
Robert Haas writes:
> On Wed, May 25, 2011 at 1:04 PM, Tom Lane wrote:
>> Because the problem is not specific to TOAST tables. As things
>> currently stand, we will accept the word of an ANALYZE as gospel even if
>> it scanned 1% of the table, and completely ignore the results from a
>> VACUUM e
Tom Lane wrote:
> Robert Haas writes:
> > On Wed, May 25, 2011 at 2:13 PM, Bruce Momjian wrote:
> >> I thought the problem was that they upgraded the OS and now the encoding
> >> names changed, though they behaved the same. ?Is that now what is
> >> happening? ?Can they supply the values with dif
Heikki Linnakangas writes:
> On 25.05.2011 17:47, Tom Lane wrote:
>> [ scratches head ... ] Why does the save/restore in ExecEvalCase not
>> take care of this?
> The mistake happens during planning, when the SQL function is inlined
> and pre-evaluated.
OK, I see the problem now: we have a Case
Robert Haas writes:
> On Wed, May 25, 2011 at 2:13 PM, Bruce Momjian wrote:
>> I thought the problem was that they upgraded the OS and now the encoding
>> names changed, though they behaved the same. Is that now what is
>> happening? Can they supply the values with different cases?
> Oh, hmm.
Robert Haas writes:
> I think getting it working is probably a good first goal. I am not
> really sure that we want to commit it that way, and I think my vote
> would be for you to work on the approach we discussed before rather
> than this one, but it's your project, and I think you'll probably
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mar may 24 17:11:17 -0400 2011:
>> Right. It would also increase the cognitive load on the user to have
>> to remember the command-line go-to-line-number switch for his editor.
>> So I don't particularly want to redesign this feature.
On Wed, May 25, 2011 at 3:05 PM, Simon Riggs wrote:
> On Wed, May 25, 2011 at 3:41 PM, Simon Riggs wrote:
>> On Wed, May 25, 2011 at 2:43 PM, Leonardo Francalanci
>> wrote:
Da: Simon Riggs
I can't find a clear discussion of what you are trying to do, and how,
just a URL back to
On ons, 2011-04-27 at 18:14 -0400, Noah Misch wrote:
> Enthusiastic +1 for this concept. There's at least one rough edge: it fails
> if
> you have another postmaster running on port 5432.
This has now been addressed: pg_upgrade accepts PGPORT settings.
Attached is a slightly updated patch runs t
2011/5/25 Alvaro Herrera :
> Excerpts from Cédric Villemain's message of mié may 25 13:24:01 -0400 2011:
>
>> > Well, we only actually need to store one number, because you can figure
>> > out a much more precise number-of-pages figure with pg_relation_size()
>> > divided by configured page size.
>
On Wed, May 25, 2011 at 10:41 AM, Simon Riggs wrote:
> OK, thats clear. Thanks.
>
> That formatting sounds quite complex.
>
> I would propose we split this into 2 WAL records: xl_xact_commit and
> xl_xact_commit_with_info
>
> xl_xact_commit doesn't have any flags, counts or arrays.
>
> xl_xact_com
On Wed, May 25, 2011 at 3:41 PM, Simon Riggs wrote:
> On Wed, May 25, 2011 at 2:43 PM, Leonardo Francalanci
> wrote:
>>> Da: Simon Riggs
>>> I can't find a clear discussion of what you are trying to do, and how,
>>> just a URL back to a complex discussion on another topic.
>>
>>
>> While tryi
On Wed, May 25, 2011 at 2:13 PM, Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> Excerpts from Robert Haas's message of mié may 25 13:33:41 -0400 2011:
>> > On Wed, May 25, 2011 at 1:22 PM, Bruce Momjian wrote:
>>
>> > > I can easily remove dashes before the compare if people like that idea
>> >
On Wed, May 25, 2011 at 12:34:59PM +0100, Simon Riggs wrote:
> On Wed, May 25, 2011 at 6:16 AM, Heikki Linnakangas
> wrote:
>
> >> To achieve that, I'm thinking to change walsender so that, when the
> >> standby
> >> has caught up with the master, it sends back the message indicating that
> >> to
I think the command 'where' does the same. And the command showed something
which looked like was part of evaluation...it got me confused. Anyways,
thanks robert. I will check that too. I did not know the 'bt' command.
--
Sent from my Android
On 25 May 2011 23:02, "Robert Haas" wrote:
While I was working on automatic translation of PostgreSQL's
documentation from SGML to XML, I found some minor issues.
In the file doc/src/sgml/ecpg.sgml there are many lines of C code
containing unescaped '<' characters.
In the file doc/src/sgml/array.sgml there is a tag which has a case
mismat
Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of mi?? may 25 13:33:41 -0400 2011:
> > On Wed, May 25, 2011 at 1:22 PM, Bruce Momjian wrote:
>
> > > I can easily remove dashes before the compare if people like that idea
> > > --- I think you could argue that a dash is not significant
On Wed, May 25, 2011 at 1:43 PM, Pavan Deolasee
wrote:
> I think the point is you can not *always* put it just after the line
> pointer array without possibly shuffling the tuples. Remember we need
> to put the LSN when the dead line pointer is generated because we
> decided to prune away the dead
On Tue, May 24, 2011 at 22:31, Jaime Casanova wrote:
> On Tue, May 24, 2011 at 8:52 PM, Fujii Masao wrote:
>
>> + primary_xlp_magic = atoi(PQgetvalue(res, 0, 2));
>>
>> You wrongly get the third field (i.e., current xlog location) as the
>> WAL version.
>> You should call PQgetvalue(res, 0,
On Wed, May 25, 2011 at 10:36 PM, Robert Haas wrote:
>
>> I don't see how you'd store
>> anything in the hole without it being in a fixed place, where it would
>> eventually be hit by either the line pointer array or tuple data.
>
> The point is that it doesn't matter. Suppose we put it just aft
On Wed, May 25, 2011 at 1:37 PM, Hitoshi Harada wrote:
>> How do you decide whether or not to push down?
>
> Yeah, that's the problem. In addition to the conditions of join-qual
> == grouping key && outer is unique on qual, we need some criteria if
> it should be done. At first I started to think
Excerpts from Tom Lane's message of mar may 24 17:11:17 -0400 2011:
> Right. It would also increase the cognitive load on the user to have
> to remember the command-line go-to-line-number switch for his editor.
> So I don't particularly want to redesign this feature. However, I can
> see the pos
Excerpts from Robert Haas's message of mié may 25 13:33:41 -0400 2011:
> On Wed, May 25, 2011 at 1:22 PM, Bruce Momjian wrote:
> > I can easily remove dashes before the compare if people like that idea
> > --- I think you could argue that a dash is not significant, unless "ab-c"
> > and "a-bc" ar
On Mon, May 23, 2011 at 11:08:40PM -0400, Robert Haas wrote:
>
> I don't really like the idea of adding a GUC for this, unless we
> convince ourselves that nothing else is sensible. I mean, that leads
> to conversations like this:
>
> Newbie: My query is slow.
> Hacker: Turn on enable_magic_pixi
Excerpts from Cédric Villemain's message of mié may 25 13:24:01 -0400 2011:
> > Well, we only actually need to store one number, because you can figure
> > out a much more precise number-of-pages figure with pg_relation_size()
> > divided by configured page size.
> I may miss something but we nee
2011/5/26 Robert Haas :
> On Wed, May 25, 2011 at 10:35 AM, Hitoshi Harada wrote:
>> 2011/5/25 Hitoshi Harada :
>>> So I'm still
>>> thinking which of pulling up and parameterized scan is better.
>>
>> After more investigation I came up with third idea, pushing down
>> RangeTblEntry to aggregate s
On Wed, May 25, 2011 at 1:22 PM, Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> Excerpts from Bruce Momjian's message of mar may 24 15:59:59 -0400 2011:
>>
>> > > I think you misread what I wrote, or I misexplained it, but never
>> > > mind. Matching locale names case-insensitively sounds reason
On Wed, May 25, 2011 at 12:34 PM, Vaibhav Kaushal
wrote:
> But somehow the execevalvar is being called. When i changed the logic of its
> working to use slot_getattr instead of cute_datum_array for the first run /
> call, everything just worked!
This is what gdb is for... set a breakpoint on that
2011/5/25 Alvaro Herrera :
> Excerpts from Kevin Grittner's message of mié may 25 12:37:24 -0400 2011:
>> Tom Lane wrote:
>>
>> > I don't know what client-side code might be looking at
>> > relpages/reltuples.
>>
>> I know that I find reltuples useful for getting an "accurate enough"
>> sense of r
On Wed, May 25, 2011 at 1:15 PM, Robert Haas wrote:
> I agree that if VACUUM scanned 99% of the table, it's probably fine to
> use its numbers. It's also fine to use the numbers from ANALYZE,
> because those pages are chosen randomly. What bothers me is the idea
> of using a small *non-random* s
On Wed, May 25, 2011 at 1:06 PM, Greg Smith wrote:
> On 05/24/2011 04:34 PM, Robert Haas wrote:
>>
>> we could name this feature "partial full page writes" and enable it
>> either with a setting of full_page_writes=partial
>
> +1 to overloading the initial name, but only if the parameter is named
On 25.05.2011 20:11, Tom Lane wrote:
Heikki Linnakangas writes:
On 25.05.2011 17:47, Tom Lane wrote:
[ scratches head ... ] Why does the save/restore in ExecEvalCase not
take care of this?
The mistake happens during planning, when the SQL function is inlined
and pre-evaluated.
Hm. I'm i
But somehow the execevalvar is being called. When i changed the logic of its
working to use slot_getattr instead of cute_datum_array for the first run /
call, everything just worked!
This would indicate surely that the function does get called at least once
before being called by executor for qual
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of mar may 24 15:59:59 -0400 2011:
>
> > > I think you misread what I wrote, or I misexplained it, but never
> > > mind. Matching locale names case-insensitively sounds reasonable to
> > > me, unless someone has reason to believe it wi
On 05/24/2011 04:34 PM, Robert Haas wrote:
we could name this feature "partial full page writes" and enable it
either with a setting of full_page_writes=partial
+1 to overloading the initial name, but only if the parameter is named
'maybe', 'sometimes', or 'perhaps'.
I've been looking into a
On Wed, May 25, 2011 at 1:04 PM, Tom Lane wrote:
> [ shrug... ] When you don't have complete information, it's *always*
> the case that you will sometimes make a mistake. That's not
> justification for paralysis, especially not when the existing code is
> demonstrably broken.
>
> What occurs to
Excerpts from Robert Haas's message of mié may 25 12:54:28 -0400 2011:
> I don't know. That's maybe better, but I'd be willing to wager that
> in some cases it will just slow down the rate at which we converge to
> a completely incorrect value, while in other cases it'll fail to
> update the data
Heikki Linnakangas writes:
> On 25.05.2011 17:47, Tom Lane wrote:
>> [ scratches head ... ] Why does the save/restore in ExecEvalCase not
>> take care of this?
> The mistake happens during planning, when the SQL function is inlined
> and pre-evaluated.
Hm. I'm inclined to think this may be mo
On 25.05.2011 17:47, Tom Lane wrote:
Heikki Linnakangas writes:
While looking at fixing the multiple-evaluation issue in IN and BETWEEN
discussed a while ago, I realized that the current assumption that only
one CaseTestExpr placeholder needs to be valid at any given time is not
true.
[ scrat
On Wed, May 25, 2011 at 12:48 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié may 25 12:27:38 -0400 2011:
>> On Wed, May 25, 2011 at 10:07 AM, Pavan Deolasee
>> wrote:
>
>> > I think if are reclaiming LP_DEAD line pointers only while
>> > defragmenting the page, we can alwa
Robert Haas writes:
> On Wed, May 25, 2011 at 12:41 PM, Tom Lane wrote:
>> Yeah, I had been thinking about the latter point. We could be
>> conservative and just keep the reported tuple density the same (ie,
>> update relpages to the new correct value, while setting reltuples so
>> that the dens
Excerpts from Kevin Grittner's message of mié may 25 12:37:24 -0400 2011:
> Tom Lane wrote:
>
> > I don't know what client-side code might be looking at
> > relpages/reltuples.
>
> I know that I find reltuples useful for getting an "accurate enough"
> sense of rows in a table (or set of tables
On Wed, May 25, 2011 at 12:41 PM, Tom Lane wrote:
> Yeah, I had been thinking about the latter point. We could be
> conservative and just keep the reported tuple density the same (ie,
> update relpages to the new correct value, while setting reltuples so
> that the density ratio doesn't change).
Excerpts from Robert Haas's message of mié may 25 12:27:38 -0400 2011:
> On Wed, May 25, 2011 at 10:07 AM, Pavan Deolasee
> wrote:
> > I think if are reclaiming LP_DEAD line pointers only while
> > defragmenting the page, we can always reclaim the space for the LSN,
> > irrespective of where we s
On Wed, May 25, 2011 at 10:17 AM, Greg Smith wrote:
>> This data would probably need to be kept separately for each table or
>> index, as some tables or indexes
>> may be mostly or fully in cache or on faster physical media than others,
>> although in the absence of other
>> data about a specific
Please find the updated patch. I have added this "+Olibmerrno" compile flag
check in configure/configure.in file.
OS
HP-UX B.11.31 U ia64
without patch
---
postgres=# select acos(2);
acos
--
NaN
(1 row)
with patch
---
postgres=# select acos(2);
ERROR: input is
@pavan - thanks a lot. Will try it when i go to desktop the next time.
--
Sent from my Android
On 25 May 2011 15:33, "Pavan Deolasee" wrote:
> On Wed, May 25, 2011 at 3:22 PM, Vaibhav Kaushal <
> vaibhavkaushal...@gmail.com> wrote:
>
>> I see that the target list to be scanned is handled by "Exec
Robert Haas writes:
> On Wed, May 25, 2011 at 11:47 AM, Tom Lane wrote:
>> 2. Revise the vacuum code so that it doesn't skip updating the pg_class
>> entries. We could have it count the number of pages it skipped, rather
>> than just keeping a bool, and then scale up the rel_tuples count to be
>
Excerpts from Bruce Momjian's message of mar may 24 15:59:59 -0400 2011:
> > I think you misread what I wrote, or I misexplained it, but never
> > mind. Matching locale names case-insensitively sounds reasonable to
> > me, unless someone has reason to believe it will blow up.
>
> OK, that's what
Tom Lane wrote:
> I don't know what client-side code might be looking at
> relpages/reltuples.
I know that I find reltuples useful for getting an "accurate enough"
sense of rows in a table (or set of tables) without resorting to
count(*). I'd be OK with any two of pages, tuples, and density;
On Wed, May 25, 2011 at 10:07 AM, Pavan Deolasee
wrote:
>> I'm confused. A major point of the approach I was proposing was to
>> avoid having to move tuples around.
>
> Well, I am not sure how you can always guarantee to make space
> available for the LSN without moving tuples , irrespective of w
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mié may 25 11:47:52 -0400 2011:
>> I can see two basic approaches we might take here:
>>
>> 1. Modify autovacuum to use something from the stats collector, rather
>> than reltuples, to make its decisions. I'm not too clear on why
>> r
On Wed, May 25, 2011 at 11:47 AM, Tom Lane wrote:
> 2. Revise the vacuum code so that it doesn't skip updating the pg_class
> entries. We could have it count the number of pages it skipped, rather
> than just keeping a bool, and then scale up the rel_tuples count to be
> approximately right by as
Simon Riggs wrote:
> On Tue, May 24, 2011 at 6:37 PM, Robert Haas wrote:
>
> >> That being said, it's a slight extra cost for all fast-path lockers to
> >> benefit
> >> the strong lockers, so I'm not prepared to guess whether it will pay off.
> >
> > Yeah. ?Basically this entire idea is about tr
On Wed, May 25, 2011 at 10:35 AM, Hitoshi Harada wrote:
> 2011/5/25 Hitoshi Harada :
>> So I'm still
>> thinking which of pulling up and parameterized scan is better.
>
> After more investigation I came up with third idea, pushing down
> RangeTblEntry to aggregate subquery. This sounds like a craz
On Wed, May 25, 2011 at 10:13 AM, Bruce Momjian wrote:
>> > Idempotent does seem like the most promising idea.
>>
>> I tend to agree with you, but I'm worried it won't actually work out
>> to a win. By the time we augment the records with enough additional
>> information we may have eaten up a lo
Excerpts from Tom Lane's message of mié may 25 11:47:52 -0400 2011:
> I think I see what must be going on here: that toast table must contain
> a long run of all-visible-according-to-the-VM pages (which is hardly a
> surprising situation). This results in VACUUM choosing not to update
> the pg_cl
On Wed, May 25, 2011 at 10:32 AM, Simon Riggs wrote:
> On Wed, May 25, 2011 at 3:24 PM, Tom Lane wrote:
>> Simon Riggs writes:
>>> I hear that CF manager is a difficult role for a single individual.
>>> So it makes sense to split that role between multiple people.
>>
>>> I volunteer to be the CF
Heikki Linnakangas writes:
> While looking at fixing the multiple-evaluation issue in IN and BETWEEN
> discussed a while ago, I realized that the current assumption that only
> one CaseTestExpr placeholder needs to be valid at any given time is not
> true.
[ scratches head ... ] Why does the
2011/5/26 Tom Lane :
> Hitoshi Harada writes:
>> 2011/5/25 Hitoshi Harada :
>>> So I'm still
>>> thinking which of pulling up and parameterized scan is better.
>
>> After more investigation I came up with third idea, pushing down
>> RangeTblEntry to aggregate subquery. This sounds like a crazy ide
Florian Helmberger writes:
> On 25.05.11 04:47, Tom Lane wrote:
>> Florian Helmberger writes:
>>> I'm running a production database with PostgreSQL 9.0.3 (64-bit) on
>>> Debian 5.0.4 and have an issue with a TOAST table and far to frequent
>>> autovacuum runs.
>>>
>>> I think I've pinned the pro
On Wed, May 25, 2011 at 2:43 PM, Leonardo Francalanci wrote:
>> Da: Simon Riggs
>> I can't find a clear discussion of what you are trying to do, and how,
>> just a URL back to a complex discussion on another topic.
>
>
> While trying to write a patch to allow changing an unlogged table into
> a
On Wed, May 25, 2011 at 8:56 AM, Simon Riggs wrote:
> On Wed, May 25, 2011 at 1:44 PM, Robert Haas wrote:
>> On Wed, May 25, 2011 at 8:27 AM, Simon Riggs wrote:
>>> I got a bit lost with the description of a potential solution. It
>>> seemed like you were unaware that there is a local lock and a
Hitoshi Harada writes:
> 2011/5/25 Hitoshi Harada :
>> So I'm still
>> thinking which of pulling up and parameterized scan is better.
> After more investigation I came up with third idea, pushing down
> RangeTblEntry to aggregate subquery. This sounds like a crazy idea,
Yes, it sure does. Won't
Alvaro Herrera writes:
> Excerpts from Vaibhav Kaushal's message of mié may 25 05:52:32 -0400 2011:
>> If the above is confusing, I just want to ask: "Is expression evaluator,
>> even in part responsible for {PLANNEDSTMT creation?"
> Yeah, as far as I understood Tom's talk, the expr evaluator is
Excerpts from Vaibhav Kaushal's message of mié may 25 05:52:32 -0400 2011:
> If the above is confusing, I just want to ask: "Is expression evaluator,
> even in part responsible for {PLANNEDSTMT creation?"
Yeah, as far as I understood Tom's talk, the expr evaluator is used to
reduce some expressio
2011/5/25 Hitoshi Harada :
> So I'm still
> thinking which of pulling up and parameterized scan is better.
After more investigation I came up with third idea, pushing down
RangeTblEntry to aggregate subquery. This sounds like a crazy idea,
but it seems to me like it is slightly easier than pulling
Simon Riggs writes:
> On Wed, May 25, 2011 at 1:44 PM, Robert Haas wrote:
>> On Wed, May 25, 2011 at 8:27 AM, Simon Riggs wrote:
>>> Design seemed relatively easy from there: put local lock table in
>>> shared memory for all procs. We then have a use_strong_lock at proc
>>> and at transaction le
On Wed, May 25, 2011 at 3:24 PM, Tom Lane wrote:
> Simon Riggs writes:
>> I hear that CF manager is a difficult role for a single individual.
>> So it makes sense to split that role between multiple people.
>
>> I volunteer to be the CF manager for Replication, and also for
>> Performance. ...
>>
Sorry, email sent without body.
Fixed some English mistakes.
commitlog_lessbytes02.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon Riggs writes:
> I hear that CF manager is a difficult role for a single individual.
> So it makes sense to split that role between multiple people.
> I volunteer to be the CF manager for Replication, and also for
> Performance. ...
> Patches need an eventual committer anyway, so this is a r
Michael Nolan wrote:
Based on last year's discussion of this TODO item, it seems thoughts
have been focused on estimating how much data is
being satisfied from PG's shared buffers. However, I think that's
only part of the problem.
Sure, but neither it nor what you're talking about are the r
Robert Haas wrote:
> That idea has the additional advantage of confusing the level of
> detail of our WAL logging (minimal vs. archive vs. hot standby) with
> the mechanism used to protect against torn pages (full page writes vs.
> idempotent WAL records vs. prayer). When they set it wrong and
> d
On Wed, May 25, 2011 at 5:57 PM, Robert Haas wrote:
>
> Alternatively, it's possible that we'd be better off vacuuming the
> table more often (say, autovacuum_vacuum_scale_factor=0.10 or 0.08 or
> something) but only doing the index scans every once in a while when
> enough dead line pointers hav
* Simon Riggs (si...@2ndquadrant.com) wrote:
> So it makes sense to split that role between multiple people.
I agree that it'd be good to have multiple people supporting the CF.
I've been considering volunteering to be part of such a group for a
given CF.
> I volunteer to be the CF manager for Re
On Wed, May 25, 2011 at 7:20 PM, Robert Haas wrote:
> On Wed, May 25, 2011 at 7:07 AM, Pavan Deolasee
> wrote:
>>> But instead of allocating permanent space in the page header, which would
>>> both reduce (admittedly only by 8 bytes) the amount of space available
>>> for tuples, and more signific
Heikki Linnakangas writes:
> On 25.05.2011 07:42, Fujii Masao wrote:
>> To achieve that, I'm thinking to change walsender so that, when the standby
>> has caught up with the master, it sends back the message indicating that to
>> the standby. And I'm thinking to add new function (or view like
>> p
commitlog_lessbytes02.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 25, 2011 at 7:07 AM, Pavan Deolasee
wrote:
>> But instead of allocating permanent space in the page header, which would
>> both reduce (admittedly only by 8 bytes) the amount of space available
>> for tuples, and more significantly have the effect of breaking on-disk
>> compatibility,
> Da: Simon Riggs
> I can't find a clear discussion of what you are trying to do, and how,
> just a URL back to a complex discussion on another topic.
While trying to write a patch to allow changing an unlogged table into
a logged one, I had to add another int field to xl_xact_commit.
Robert H
On Wed, May 25, 2011 at 1:27 PM, Robert Haas wrote:
>> At the moment we scan indexes if we have > 0 rows to remove, which is
>> probably wasteful. Perhaps it would be better to keep a running total
>> of rows to remove, by updating pg_stats, then when we hit a certain
>> threshold in total we can
On Tue, May 24, 2011 at 9:34 PM, Robert Haas wrote:
> I'm not sure that these ideas are much good, but
> for the sake of posterity:
Both (1) and (2) seem promising to me.
Heikki mentioned (2) would only be effective if we managed to change
*all* WAL records. ISTM likely that we would find that
On Wed, May 25, 2011 at 1:44 PM, Robert Haas wrote:
> On Wed, May 25, 2011 at 8:27 AM, Simon Riggs wrote:
>> I got a bit lost with the description of a potential solution. It
>> seemed like you were unaware that there is a local lock and a shared
>> lock table, maybe just me?
>
> No, I'm not unaw
On Wed, May 25, 2011 at 8:27 AM, Simon Riggs wrote:
> I got a bit lost with the description of a potential solution. It
> seemed like you were unaware that there is a local lock and a shared
> lock table, maybe just me?
No, I'm not unaware of the local lock table. The point of this
proposal is t
On Tue, May 24, 2011 at 11:52 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> 2. The other fairly obvious alternative is to adjust our existing WAL
>> record types to be idempotent - i.e. to not rely on the existing page
>> contents. For XLOG_HEAP_INSERT, we currently store the target tid and
>>
On Tue, May 24, 2011 at 10:52 PM, Jeff Davis wrote:
> On Tue, 2011-05-24 at 16:34 -0400, Robert Haas wrote:
>> As I think about it a bit more, we'd
>> need to XLOG not only the parts of the page we actually modifying, but
>> any that the WAL record would need to be correct on replay.
>
> I don't u
1 - 100 of 114 matches
Mail list logo
