Hi Simon,
On 2015-04-20 19:21:24 +0100, Simon Riggs wrote:
> Since we have many votes in favour of change in this area I'll post a new
> version and look for an early review/commit for next release.
If I see correctly there's been no new patch version since, right? The
patch is included in the cu
On 2015-04-23 15:40:36 -0400, Robert Haas wrote:
> The issue is that you have to vacuum a table frequently enough to
> avoid accumulating bloat. The frequency with which you need to vacuum
> varies depending on the size of the table and how frequently it's
> updated. However, a large, heavily-upd
On Thu, Apr 23, 2015 at 10:44 AM, Jim Nasby wrote:
> On 4/23/15 8:25 AM, Robert Haas wrote:
>> Some users are partitioning tables just so that each
>> partition can be autovac'd separately. That really shouldn't be
>> required.
>
> Are they doing this for improved heap scan performance? Index sca
On 4/23/15 8:25 AM, Robert Haas wrote:
Some users are partitioning tables just so that each
partition can be autovac'd separately. That really shouldn't be
required.
Are they doing this for improved heap scan performance? Index scan
performance? If the table wasn't partitioned, would they nee
On Wed, Apr 22, 2015 at 5:17 PM, Bruce Momjian wrote:
> On Wed, Apr 22, 2015 at 06:07:00PM -0300, Alvaro Herrera wrote:
>> > Good point, but doesn't vacuum remove the need for pruning as it removes
>> > all the old rows?
>>
>> Sure. The point, I think, is to make autovacuum runs of some sort that
On 4/22/15 1:51 PM, Kevin Grittner wrote:
(1) WAL log the insert.
(2) Write the tuple.
(3) Hint and rewrite the tuple.
(4) WAL log the freeze of the tuple.
(5) Rewrite the frozen tuple.
(6) WAL-log the delete.
(7) Rewrite the deleted tuple.
(8) Prune and rewrite the page.
(9) Free line pointers a
On Wed, Apr 22, 2015 at 06:07:00PM -0300, Alvaro Herrera wrote:
> > Good point, but doesn't vacuum remove the need for pruning as it removes
> > all the old rows?
>
> Sure. The point, I think, is to make autovacuum runs of some sort that
> don't actually vacuum but only do HOT-pruning. Maybe thi
Bruce Momjian wrote:
> On Wed, Apr 22, 2015 at 04:36:17PM +0100, Greg Stark wrote:
> > On Mon, Apr 20, 2015 at 8:48 PM, Bruce Momjian wrote:
> > > Well, we have to assume there are many misconfigured configurations ---
> > > autovacuum isn't super-easy to configure, so we can't just blame the
> >
On Wed, Apr 22, 2015 at 04:36:17PM +0100, Greg Stark wrote:
> On Mon, Apr 20, 2015 at 8:48 PM, Bruce Momjian wrote:
> > Well, we have to assume there are many misconfigured configurations ---
> > autovacuum isn't super-easy to configure, so we can't just blame the
> > user if this makes things wor
Greg Stark wrote:
> And it's a major headache, people are always being surprised that
> their selects cause lots of I/O and slow down dramatically after
> a big update or data load has finished. It's characterized as
> "why is the database writing everything twice" (and saying it's
> actually wri
On Tue, Apr 21, 2015 at 05:07:52PM -0400, Peter Eisentraut wrote:
> On 4/21/15 4:45 PM, Jim Nasby wrote:
> > This comment made me wonder... has anyone considered handing the pruning
> > work off to a bgworker, at least for SELECTs? That means the selects
> > themselves wouldn't be burdened by the a
On 4/22/15 11:37 AM, Jim Nasby wrote:
> On 4/21/15 4:07 PM, Peter Eisentraut wrote:
>> On 4/21/15 4:45 PM, Jim Nasby wrote:
>> In order for a background worker to keep up with some of the workloads
>> that have been presented as counterexamples, you'd need multiple
>> background workers operating i
On Tue, Apr 21, 2015 at 04:36:53PM -0400, Robert Haas wrote:
> > Keep in mind there's a disconnect between dirtying a page and writing it
> > to storage. A page could remain dirty for a long time in the buffer
> > cache. This writing of sequential pages would occur at checkpoint time
> > only, wh
On 4/21/15 4:07 PM, Peter Eisentraut wrote:
On 4/21/15 4:45 PM, Jim Nasby wrote:
In order for a background worker to keep up with some of the workloads
that have been presented as counterexamples, you'd need multiple
background workers operating in parallel and preferring to work on
certain parts
On Mon, Apr 20, 2015 at 8:48 PM, Bruce Momjian wrote:
>
>> But if the entire table is very hot, I think that that is just another of way
>> of saying that autovacuum is horribly misconfigured. I think the purpose of
>
> Well, we have to assume there are many misconfigured configurations ---
> aut
On 4/21/15 4:45 PM, Jim Nasby wrote:
> This comment made me wonder... has anyone considered handing the pruning
> work off to a bgworker, at least for SELECTs? That means the selects
> themselves wouldn't be burdened by the actual prune work, only in
> notifying the bgworker. While that's not going
On Tue, Apr 21, 2015 at 11:04 AM, Bruce Momjian wrote:
> Yes, it might be too much optimization to try to get the checkpoint to
> flush all those pages sequentially, but I was thinking of our current
> behavior where, after an update of all rows, we effectively write out
> the entire table because
On 4/21/15 10:04 AM, Bruce Momjian wrote:
One thing to consider is how we handle pruning of index scans that hit
multiple heap pages. Do we still write X% of the pages in the table, or
%X of the heap pages we actually access via SELECT? With the
write-then-skip approach, we would do X% of the p
On Mon, Apr 20, 2015 at 6:13 PM, Alvaro Herrera
wrote:
> Bruce Momjian wrote:
>> On Mon, Apr 20, 2015 at 04:19:22PM -0300, Alvaro Herrera wrote:
>> > Bruce Momjian wrote:
>> > This seems simple to implement: keep two counters, where the second one
>> > is pages we skipped cleanup in. Once that co
On Mon, Apr 20, 2015 at 07:13:38PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Mon, Apr 20, 2015 at 04:19:22PM -0300, Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > >
> > > This seems simple to implement: keep two counters, where the second one
> > > is pages we skipped cleanu
Bruce Momjian wrote:
> On Mon, Apr 20, 2015 at 04:19:22PM -0300, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > This seems simple to implement: keep two counters, where the second one
> > is pages we skipped cleanup in. Once that counter hits SOME_MAX_VALUE,
> > reset the first counter so
On Mon, Apr 20, 2015 at 09:56:20PM +0100, Simon Riggs wrote:
> On 20 April 2015 at 20:28, Jeff Janes wrote:
>
>
> But why should 1 SELECT or 20 SELECTs or 200 SELECTs have to do a job,
> while the user waits, which is fundamentally VACUUM's duty to do in the
> background?
>
>
> A
On Mon, Apr 20, 2015 at 04:19:22PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > I think the limit has to be in terms of a percentage of the table size.
> > For example, if we do one SELECT on a table with all non-dirty pages, it
> > would be good to know that 5% of the pages were pru
On Mon, Apr 20, 2015 at 3:28 PM, Jeff Janes wrote:
> But why should 1 SELECT or 20 SELECTs or 200 SELECTs have to do a job, while
> the user waits, which is fundamentally VACUUM's duty to do in the
> background? If there are a handful of very hot pages, then it makes sense
> not to wait for vacuu
On 20 April 2015 at 20:28, Jeff Janes wrote:
> But why should 1 SELECT or 20 SELECTs or 200 SELECTs have to do a job,
> while the user waits, which is fundamentally VACUUM's duty to do in the
> background?
>
Agreed. I don't see a % as giving us anything at all.
The idea is that we want to turn
On Mon, Apr 20, 2015 at 12:28:11PM -0700, Jeff Janes wrote:
> But why should 1 SELECT or 20 SELECTs or 200 SELECTs have to do a job, while
> the user waits, which is fundamentally VACUUM's duty to do in the background?
> If there are a handful of very hot pages, then it makes sense not to wait for
On Mon, Apr 20, 2015 at 04:19:22PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > I think the limit has to be in terms of a percentage of the table size.
> > For example, if we do one SELECT on a table with all non-dirty pages, it
> > would be good to know that 5% of the pages were pru
On Mon, Apr 20, 2015 at 10:33 AM, Bruce Momjian wrote:
> On Thu, Apr 16, 2015 at 03:41:54PM +0100, Simon Riggs wrote:
> > That is how we arrive at the idea of a cleanup limit, further enhanced
> by a
> > limit that applies only to dirtying clean blocks, which we have 4?
> recent votes
> > in favo
Bruce Momjian wrote:
> I think the limit has to be in terms of a percentage of the table size.
> For example, if we do one SELECT on a table with all non-dirty pages, it
> would be good to know that 5% of the pages were pruned --- that tells me
> that another 19 SELECTs will totally prune the tab
On 20 April 2015 at 18:33, Bruce Momjian wrote:
> Also, I am also not sure we should be designing features at this stage
> in our release process.
>
I see this more as a process of gaining approval. I don't think patches at
the back of the queue should get the "its too late treatment" just beca
On Thu, Apr 16, 2015 at 03:41:54PM +0100, Simon Riggs wrote:
> That is how we arrive at the idea of a cleanup limit, further enhanced by a
> limit that applies only to dirtying clean blocks, which we have 4? recent
> votes
> in favour of.
>
> I would personally be in favour of a parameter to cont
On 2015-04-20 01:04:18 -0700, Jeff Janes wrote:
> Was this reproducible?
Yes, at least with an old version of the patch.
I don't think you could see a difference using exactly that with the
newer versions which have the 5 page limit. After all it'll pretty much
never reach it.
> > That's not a u
On Mon, Sep 29, 2014 at 2:13 AM, Andres Freund wrote:
>
> On 2014-09-28 19:51:36 +0100, Simon Riggs wrote:
> > On 27 September 2014 09:29, Andres Freund wrote:
> > > On 2014-09-27 10:23:33 +0300, Heikki Linnakangas wrote:
> > >> This patch has gotten a fair amount of review, and has been
rewritte
Andres Freund wrote:
> On 2015-04-16 10:20:20 -0300, Alvaro Herrera wrote:
> > I think you're failing to consider that in the patch there is a
> > distinction between read-only page accesses and page updates. During a
> > page update, HOT cleanup is always done even with the patch, so there
> > wo
On 16 April 2015 at 15:21, Andres Freund wrote:
> On 2015-04-16 10:20:20 -0300, Alvaro Herrera wrote:
> > I think you're failing to consider that in the patch there is a
> > distinction between read-only page accesses and page updates. During a
> > page update, HOT cleanup is always done even wi
On 2015-04-16 10:20:20 -0300, Alvaro Herrera wrote:
> I think you're failing to consider that in the patch there is a
> distinction between read-only page accesses and page updates. During a
> page update, HOT cleanup is always done even with the patch, so there
> won't be any additional bloat tha
On Thu, Apr 16, 2015 at 6:50 PM, Alvaro Herrera
wrote:
> Pavan Deolasee wrote:
> > On Thu, Apr 16, 2015 at 2:47 PM, Greg Stark wrote:
>
> > > From a holistic point of view the question is how many times is a given
> > > hit chain going to need to be followed before it's pruned. Or to put it
> >
Pavan Deolasee wrote:
> On Thu, Apr 16, 2015 at 2:47 PM, Greg Stark wrote:
> > From a holistic point of view the question is how many times is a given
> > hit chain going to need to be followed before it's pruned. Or to put it
> > another way, how expensive is creating a hot chain. Does it cause
On Thu, Apr 16, 2015 at 2:47 PM, Greg Stark wrote:
>
> On 15 Apr 2015 15:43, "Simon Riggs" wrote:
> >
> > It all depends upon who is being selfish. Why is a user "selfish" for
> > not wanting to clean every single block they scan, when the people
> > that made the mess do nothing and go faster 1
On 15 Apr 2015 15:43, "Simon Riggs" wrote:
>
> It all depends upon who is being selfish. Why is a user "selfish" for
> not wanting to clean every single block they scan, when the people
> that made the mess do nothing and go faster 10 minutes from now?
> Randomly and massively penalising large SEL
On Wed, Apr 15, 2015 at 6:10 AM, Andres Freund wrote:
>> > Of
>> > course, that applies in all cases, but when the page is already dirty,
>> > the cost of pruning it is probably quite small - we're going to have
>> > to write the page anyway, and pruning it before it gets evicted
>> > (perhaps eve
On 15 April 2015 at 16:01, Alvaro Herrera wrote:
> Simon Riggs wrote:
>> On 15 April 2015 at 12:39, Robert Haas wrote:
>
>> On 04/15/2015 05:44 PM, Alvaro Herrera wrote:
>> > Robert's proposal is "when reading a page, if dirty HOT-clean it; if not
>> > dirty, also HOT-clean it but only 5 times in
Simon Riggs wrote:
> On 15 April 2015 at 12:39, Robert Haas wrote:
> On 04/15/2015 05:44 PM, Alvaro Herrera wrote:
> > Robert's proposal is "when reading a page, if dirty HOT-clean it; if not
> > dirty, also HOT-clean it but only 5 times in each scan". This runs
> > HOT-cleanup some number of ti
On 15 April 2015 at 12:39, Robert Haas wrote:
> On Wed, Apr 15, 2015 at 8:42 AM, Simon Riggs wrote:
>>> I won't take responsibility for paying my neighbor's tax bill, but I
>>> might take responsibility for picking up his mail while he's on
>>> holiday.
>>
>> That makes it sound like this is an o
On Wed, Apr 15, 2015 at 8:42 AM, Simon Riggs wrote:
>> I won't take responsibility for paying my neighbor's tax bill, but I
>> might take responsibility for picking up his mail while he's on
>> holiday.
>
> That makes it sound like this is an occasional, non-annoying thing.
>
> It's more like, who
On 04/15/2015 07:11 PM, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
On 04/15/2015 05:44 PM, Alvaro Herrera wrote:
Robert's proposal is "when reading a page, if dirty HOT-clean it; if not
dirty, also HOT-clean it but only 5 times in each scan". This runs
HOT-cleanup some number of times (
Heikki Linnakangas wrote:
> On 04/15/2015 05:44 PM, Alvaro Herrera wrote:
> >Robert's proposal is "when reading a page, if dirty HOT-clean it; if not
> >dirty, also HOT-clean it but only 5 times in each scan". This runs
> >HOT-cleanup some number of times (as many as there are dirty), and
> >caus
On 04/15/2015 05:44 PM, Alvaro Herrera wrote:
Simon Riggs wrote:
On 15 April 2015 at 09:10, Andres Freund wrote:
I don't really see the downside to this suggestion.
The suggestion makes things better than they are now but is still less
than I have proposed.
If what you both mean is "IMHO
Simon Riggs wrote:
> On 15 April 2015 at 09:10, Andres Freund wrote:
> > I don't really see the downside to this suggestion.
>
> The suggestion makes things better than they are now but is still less
> than I have proposed.
>
> If what you both mean is "IMHO this is an acceptable compromise", I
On 15 April 2015 at 09:10, Andres Freund wrote:
> On 2015-04-15 08:42:33 -0400, Simon Riggs wrote:
>> > Because it makes it subsequent accesses to the page cheaper.
>>
>> Cheaper for whom?
>
> Everyone.
I think what you mean is "Everyone else". It is demonstrably quicker
and more consistent for a
On 2015-04-15 08:42:33 -0400, Simon Riggs wrote:
> > Because it makes it subsequent accesses to the page cheaper.
>
> Cheaper for whom?
Everyone. Including further readers. Following HOT chains in read mostly
workloads can be really expensive. If you have workloads with a 'hot'
value range that's
On 15 April 2015 at 08:04, Robert Haas wrote:
> On Wed, Apr 15, 2015 at 3:37 AM, Simon Riggs wrote:
>> On 14 April 2015 at 21:53, Robert Haas wrote:
>>> Peter commented previously that README.HOT should get an update. The
>>> relevant section seems to be "When can/should we prune or
>>> defragm
On Wed, Apr 15, 2015 at 3:37 AM, Simon Riggs wrote:
> On 14 April 2015 at 21:53, Robert Haas wrote:
>> Peter commented previously that README.HOT should get an update. The
>> relevant section seems to be "When can/should we prune or
>> defragment?".
>
> That's easy enough to change once we agree
On 14 April 2015 at 21:53, Robert Haas wrote:
> Peter commented previously that README.HOT should get an update. The
> relevant section seems to be "When can/should we prune or
> defragment?".
That's easy enough to change once we agree to commit.
> I wonder if it would be a useful heuristic to
On Tue, Apr 14, 2015 at 6:07 PM, Simon Riggs wrote:
> On 11 March 2015 at 20:55, Peter Eisentraut wrote:
>> I don't know how to move forward. We could give users a knob: This
>> might make your queries faster or not -- good luck. But of course
>> nobody will like that either.
>
> What is clear
On 4/14/15 6:07 PM, Simon Riggs wrote:
> On 11 March 2015 at 20:55, Peter Eisentraut wrote:
>
>> I don't know how to move forward. We could give users a knob: This
>> might make your queries faster or not -- good luck. But of course
>> nobody will like that either.
>
> What is clear is that la
On 11 March 2015 at 20:55, Peter Eisentraut wrote:
> I don't know how to move forward. We could give users a knob: This
> might make your queries faster or not -- good luck. But of course
> nobody will like that either.
What is clear is that large SELECT queries are doing the work VACUUM
shoul
On Thu, Mar 12, 2015 at 3:48 PM, Peter Eisentraut wrote:
> On 3/12/15 5:41 AM, Andres Freund wrote:
>> On 2015-03-11 20:55:18 -0400, Peter Eisentraut wrote:
>>> I don't think so. Andres basically wanted a nontrival algorithm to
>>> determine how much pruning to do during a read-only scan. And Ro
On 3/12/15 5:41 AM, Andres Freund wrote:
> On 2015-03-11 20:55:18 -0400, Peter Eisentraut wrote:
>> I don't think so. Andres basically wanted a nontrival algorithm to
>> determine how much pruning to do during a read-only scan. And Robert
>> basically said, that's not really possible.
>
> I don'
On 2015-03-11 20:55:18 -0400, Peter Eisentraut wrote:
> I don't think so. Andres basically wanted a nontrival algorithm to
> determine how much pruning to do during a read-only scan. And Robert
> basically said, that's not really possible.
I don't think either of us made really strong statements
On 3/9/15 1:36 PM, Jeff Janes wrote:
> Did versions 7 and 8 of this patch address Andres' concern about
> performance regressions?
I don't think so. Andres basically wanted a nontrival algorithm to
determine how much pruning to do during a read-only scan. And Robert
basically said, that's not re
On 12/17/14 3:39 AM, Simon Riggs wrote:
> On 15 December 2014 at 20:26, Jeff Janes wrote:
>
>> I still get the compiler error in contrib:
>>
>> pgstattuple.c: In function 'pgstat_heap':
>> pgstattuple.c:279: error: too few arguments to function
>> 'heap_beginscan_strat'
>>
>> Should it pass false
On Wed, Dec 17, 2014 at 12:39 AM, Simon Riggs wrote:
> On 15 December 2014 at 20:26, Jeff Janes wrote:
>
> > I still get the compiler error in contrib:
> >
> > pgstattuple.c: In function 'pgstat_heap':
> > pgstattuple.c:279: error: too few arguments to function
> > 'heap_beginscan_strat'
> >
> >
On Wed, Dec 17, 2014 at 5:39 PM, Simon Riggs wrote:
> On 15 December 2014 at 20:26, Jeff Janes wrote:
>
> > I still get the compiler error in contrib:
> >
> > pgstattuple.c: In function 'pgstat_heap':
> > pgstattuple.c:279: error: too few arguments to function
> > 'heap_beginscan_strat'
> >
> >
On 15 December 2014 at 20:26, Jeff Janes wrote:
> I still get the compiler error in contrib:
>
> pgstattuple.c: In function 'pgstat_heap':
> pgstattuple.c:279: error: too few arguments to function
> 'heap_beginscan_strat'
>
> Should it pass false for the always_prune?
Yes.
New version attached.
On Thu, Dec 11, 2014 at 7:24 PM, Simon Riggs wrote:
>
> On 17 November 2014 at 22:08, Simon Riggs wrote:
> > On 17 November 2014 21:09, Alvaro Herrera
> wrote:
> >> What happened to this patch? I'm going over something that could use
> >> the concept of "clean some stuff up when reading this pa
On 17 November 2014 at 22:08, Simon Riggs wrote:
> On 17 November 2014 21:09, Alvaro Herrera wrote:
>> What happened to this patch? I'm going over something that could use
>> the concept of "clean some stuff up when reading this page, but only if
>> we're already writing" or similar.
>>
>> I see
On 17 November 2014 21:09, Alvaro Herrera wrote:
> What happened to this patch? I'm going over something that could use
> the concept of "clean some stuff up when reading this page, but only if
> we're already writing" or similar.
>
> I see some cases were presented that had a performance decreas
What happened to this patch? I'm going over something that could use
the concept of "clean some stuff up when reading this page, but only if
we're already writing" or similar.
I see some cases were presented that had a performance decrease. Did we
get any numbers for the increase in performance
On 2014-09-29 11:31:11 +0200, Andres Freund wrote:
> On 2014-09-29 11:13:43 +0200, Andres Freund wrote:
> > I doubt it'll be hard to construct a case where it'll show. My first try
> > of using a pgbench scale 100, -M prepared, -cj8 with a custom file with
> > 1 write and 5 read transaction yielded
On 2014-09-29 11:13:43 +0200, Andres Freund wrote:
> I doubt it'll be hard to construct a case where it'll show. My first try
> of using a pgbench scale 100, -M prepared, -cj8 with a custom file with
> 1 write and 5 read transaction yielded the following on my laptop:
Hm. On second thought that te
On 2014-09-28 19:51:36 +0100, Simon Riggs wrote:
> On 27 September 2014 09:29, Andres Freund wrote:
> > On 2014-09-27 10:23:33 +0300, Heikki Linnakangas wrote:
> >> This patch has gotten a fair amount of review, and has been rewritten once
> >> during the commitfest. I think it's pretty close to b
On 27 September 2014 09:29, Andres Freund wrote:
> On 2014-09-27 10:23:33 +0300, Heikki Linnakangas wrote:
>> This patch has gotten a fair amount of review, and has been rewritten once
>> during the commitfest. I think it's pretty close to being committable, the
>> only remaining question seems to
On 2014-09-27 10:23:33 +0300, Heikki Linnakangas wrote:
> This patch has gotten a fair amount of review, and has been rewritten once
> during the commitfest. I think it's pretty close to being committable, the
> only remaining question seems to be what to do with system catalogs. I'm
> marking this
This patch has gotten a fair amount of review, and has been rewritten
once during the commitfest. I think it's pretty close to being
committable, the only remaining question seems to be what to do with
system catalogs. I'm marking this as "Returned with feedback", I take it
that Simon can proce
On Fri, Sep 19, 2014 at 5:42 PM, Andres Freund wrote:
> On 2014-09-19 17:29:08 -0400, Robert Haas wrote:
>> > I generally have serious doubts about disabling it generally for
>> > read workloads. I imagine it e.g. will significantly penalize
>> > workloads where its likely that a cleanup lock can'
On 2014-09-19 16:35:19 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On September 19, 2014 10:16:35 PM CEST, Simon Riggs
> > wrote:
> >> Are you saying this is a problem or a benefit? (and please explain
> >> why).
>
> > I have no idea what Robert is thinking of, but I'd imagine its horrib
On 19 September 2014 15:35, Tom Lane wrote:
> Having said that, this could reasonably be considered outside the scope
> of a patch that's trying to improve the behavior for user queries.
> But if the patch author doesn't want to expand the scope like that,
> ISTM he ought to ensure that the behav
On 2014-09-19 17:29:08 -0400, Robert Haas wrote:
> > I generally have serious doubts about disabling it generally for
> > read workloads. I imagine it e.g. will significantly penalize
> > workloads where its likely that a cleanup lock can't be acquired
> > every time...
>
> I share that doubt. Bu
On Fri, Sep 19, 2014 at 4:30 PM, Andres Freund wrote:
> On September 19, 2014 10:16:35 PM CEST, Simon Riggs
> wrote:
>>On 19 September 2014 13:04, Robert Haas wrote:
>>
>>> What I'm thinking about is that the smarts to enable pruning is all
>>in
>>> the executor nodes. So anything that updates
Andres Freund writes:
> On September 19, 2014 10:16:35 PM CEST, Simon Riggs
> wrote:
>> Are you saying this is a problem or a benefit? (and please explain
>> why).
> I have no idea what Robert is thinking of, but I'd imagine its horrible for
> workloads with catalog bloat. Like ones involving
On September 19, 2014 10:16:35 PM CEST, Simon Riggs
wrote:
>On 19 September 2014 13:04, Robert Haas wrote:
>
>> What I'm thinking about is that the smarts to enable pruning is all
>in
>> the executor nodes. So anything that updates the catalog without
>> going through the executor will never be
On 19 September 2014 13:04, Robert Haas wrote:
> What I'm thinking about is that the smarts to enable pruning is all in
> the executor nodes. So anything that updates the catalog without
> going through the executor will never be subject to pruning. That
> includes nearly all catalog-modifying
On Mon, Sep 15, 2014 at 5:13 PM, Simon Riggs wrote:
> On 15 September 2014 17:09, Robert Haas wrote:
>> Do we really want to disable HOT for all catalog scans?
>
> The intention of the patch is that catalog scans are treated
> identically to non-catalog scans. The idea here is that HOT cleanup
>
On 15 September 2014 22:13, Simon Riggs wrote:
> On 15 September 2014 17:09, Robert Haas wrote:
>
>> Do we really want to disable HOT for all catalog scans?
>
> The intention of the patch is that catalog scans are treated
> identically to non-catalog scans. The idea here is that HOT cleanup
> onl
El 15/09/14 18:13, Simon Riggs escribió:
> On 15 September 2014 17:09, Robert Haas wrote:
>
>> Do we really want to disable HOT for all catalog scans?
> The intention of the patch is that catalog scans are treated
> identically to non-catalog scans. The idea here is that HOT cleanup
> only occurs
El 14/09/14 17:37, Simon Riggs escribió:
> On 12 September 2014 18:19, Simon Riggs wrote:
>> On 12 September 2014 15:30, Tom Lane wrote:
>>> After a little bit I remembered there was already a function for this.
>>> So specifically, I'd suggest using ExecRelationIsTargetRelation()
>>> to decide
On 15 September 2014 17:09, Robert Haas wrote:
> Do we really want to disable HOT for all catalog scans?
The intention of the patch is that catalog scans are treated
identically to non-catalog scans. The idea here is that HOT cleanup
only occurs on scans on target relations, so only INSERT, UPDA
On Sun, Sep 14, 2014 at 4:37 PM, Simon Riggs wrote:
> On 12 September 2014 18:19, Simon Riggs wrote:
>> On 12 September 2014 15:30, Tom Lane wrote:
>
>>> After a little bit I remembered there was already a function for this.
>>> So specifically, I'd suggest using ExecRelationIsTargetRelation()
>
On 12 September 2014 18:19, Simon Riggs wrote:
> On 12 September 2014 15:30, Tom Lane wrote:
>> After a little bit I remembered there was already a function for this.
>> So specifically, I'd suggest using ExecRelationIsTargetRelation()
>> to decide whether to mark the scan as requiring pruning.
On 12 September 2014 15:30, Tom Lane wrote:
> I wrote:
>> I think there's another way to think about it: what about saying that
>> the query's target relation(s) are subject to pruning, while others
>> are not? Then you do not need an executor flag, you just need to
>> look at the estate->es_resu
I wrote:
> I think there's another way to think about it: what about saying that
> the query's target relation(s) are subject to pruning, while others
> are not? Then you do not need an executor flag, you just need to
> look at the estate->es_result_relations array (or maybe even only at
> estate-
Simon Riggs writes:
> On 12 September 2014 14:54, Alvaro Herrera wrote:
>> My idea is that we would have a new executor flag, say
>> EXEC_FLAG_READ_ONLY; we would set it on nodes that are known to be
>> read-only, and reset it on those that aren't, such as LockRows and
>> ModifyTable (obviously w
Simon Riggs wrote:
> On 12 September 2014 14:54, Alvaro Herrera wrote:
>
> > My idea is that we would have a new executor flag, say
> > EXEC_FLAG_READ_ONLY; we would set it on nodes that are known to be
> > read-only, and reset it on those that aren't, such as LockRows and
> > ModifyTable (obviou
On 12 September 2014 14:54, Alvaro Herrera wrote:
> My idea is that we would have a new executor flag, say
> EXEC_FLAG_READ_ONLY; we would set it on nodes that are known to be
> read-only, and reset it on those that aren't, such as LockRows and
> ModifyTable (obviously we need to pass it down cor
Michael Paquier wrote:
> On Fri, Sep 12, 2014 at 3:19 PM, Michael Paquier
> wrote:
> > On Mon, Feb 3, 2014 at 3:42 PM, Amit Kapila wrote:
> >> On Wed, Jan 15, 2014 at 2:43 AM, Simon Riggs wrote:
> >>> On 8 January 2014 08:33, Simon Riggs wrote:
> >>>
> >>> Patch attached, implemented to reduce
On Fri, Sep 12, 2014 at 3:19 PM, Michael Paquier
wrote:
> On Mon, Feb 3, 2014 at 3:42 PM, Amit Kapila wrote:
>> On Wed, Jan 15, 2014 at 2:43 AM, Simon Riggs wrote:
>>> On 8 January 2014 08:33, Simon Riggs wrote:
>>>
>>> Patch attached, implemented to reduce writes by SELECTs only.
>
> This patc
On Mon, Feb 3, 2014 at 3:42 PM, Amit Kapila wrote:
> On Wed, Jan 15, 2014 at 2:43 AM, Simon Riggs wrote:
>> On 8 January 2014 08:33, Simon Riggs wrote:
>>
>> Patch attached, implemented to reduce writes by SELECTs only.
This patch is registered in this CF. It does not apply anymore and
needs a
On Wed, Jan 15, 2014 at 2:43 AM, Simon Riggs wrote:
> On 8 January 2014 08:33, Simon Riggs wrote:
>
> Patch attached, implemented to reduce writes by SELECTs only.
This is really a valuable improvement over current SELECT behaviour
w.r.t Writes.
While going though patch, I observed few points,
On Wed, Jan 15, 2014 at 5:14 PM, Simon Riggs wrote:
> We already know that HOT is ineffective in areas of high contention
> (previous thread by me). Prior experience was that smaller tables
> didn't show much apparent benefit from using HOT either; its
> effectiveness was limited to medium and lar
1 - 100 of 119 matches
Mail list logo
