On 2016-06-30 23:51:18 -0400, Noah Misch wrote:
> On Thu, Jun 16, 2016 at 01:56:44PM -0500, Kevin Grittner wrote:
> > On Thu, Jun 16, 2016 at 1:32 PM, Andres Freund wrote:
> >
> > > With old_snapshot_threshold=1 I indeed can reproduce the issue. I
> > > disabled autovacuum, to make the scheduling
On Thu, Jun 16, 2016 at 01:56:44PM -0500, Kevin Grittner wrote:
> On Thu, Jun 16, 2016 at 1:32 PM, Andres Freund wrote:
>
> > With old_snapshot_threshold=1 I indeed can reproduce the issue. I
> > disabled autovacuum, to make the scheduling more predictable. But it
> > should "work" just as well w
On 2016-06-16 11:57:48 -0700, Andres Freund wrote:
> See
> https://www.postgresql.org/message-id/20160616183207.wygoktoplycdz...@alap3.anar
For posterity's sake, that was supposed to be
https://www.postgresql.org/message-id/20160616183207.wygoktoplycdz...@alap3.anarazel.de
--
Sent via pgsql-co
On 2016-06-16 13:53:01 -0500, Kevin Grittner wrote:
> On Thu, Jun 16, 2016 at 1:19 PM, Kevin Grittner wrote:
> > On Thu, Jun 16, 2016 at 11:54 AM, Andres Freund wrote:
> >> On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
>
> >>> Maybe it would help if you lay out the whole sequence of events, l
On Thu, Jun 16, 2016 at 1:32 PM, Andres Freund wrote:
> With old_snapshot_threshold=1 I indeed can reproduce the issue. I
> disabled autovacuum, to make the scheduling more predictable. But it
> should "work" just as well with autovacuum.
>
> S1: CREATE TABLE toasted(largecol text);
> INSERT
On Thu, Jun 16, 2016 at 1:19 PM, Kevin Grittner wrote:
> On Thu, Jun 16, 2016 at 11:54 AM, Andres Freund wrote:
>> On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
>>> Maybe it would help if you lay out the whole sequence of events, like:
>>>
>>> S1: Does this.
>>> S2: Does that.
>>> S1: Now doe
Hi,
On 2016-06-16 13:19:13 -0500, Kevin Grittner wrote:
> On Thu, Jun 16, 2016 at 11:54 AM, Andres Freund wrote:
> > On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
>
> >> The root of my confusion is: if we prune a tuple, we'll bump the page
> >> LSN, so any session that is still referencing th
On 2016-06-16 13:16:35 -0500, Kevin Grittner wrote:
> On Thu, Jun 16, 2016 at 1:01 PM, Andres Freund wrote:
>
> > The relevant part is the HeapTupleSatisfiesMVCC check, we're using
> > SatisfiesToast for toast lookups.
> >
> > FWIW, I just tried to reproduce this with old_snapshot_threshold = 0 -
On Thu, Jun 16, 2016 at 11:54 AM, Andres Freund wrote:
> On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
>> The root of my confusion is: if we prune a tuple, we'll bump the page
>> LSN, so any session that is still referencing that tuple will error
>> out as soon as it touches the page on which
On Thu, Jun 16, 2016 at 1:01 PM, Andres Freund wrote:
> The relevant part is the HeapTupleSatisfiesMVCC check, we're using
> SatisfiesToast for toast lookups.
>
> FWIW, I just tried to reproduce this with old_snapshot_threshold = 0 -
> but ran into the problem that I couldn't get it to vacuum any
On 2016-06-16 13:44:34 -0400, Robert Haas wrote:
> On Thu, Jun 16, 2016 at 12:54 PM, Andres Freund wrote:
> >> The root of my confusion is: if we prune a tuple, we'll bump the page
> >> LSN, so any session that is still referencing that tuple will error
> >> out as soon as it touches the page on w
On Thu, Jun 16, 2016 at 12:54 PM, Andres Freund wrote:
>> The root of my confusion is: if we prune a tuple, we'll bump the page
>> LSN, so any session that is still referencing that tuple will error
>> out as soon as it touches the page on which that tuple used to exist.
>
> Right. On the main tab
On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
> On Thu, Jun 16, 2016 at 12:14 PM, Andres Freund wrote:
> >> > The issue isn't there without the feature, because we (should) never
> >> > access a tuple/detoast a column when it's invisible enough for the
> >> > corresponding toast tuple to be vac
On Thu, Jun 16, 2016 at 12:14 PM, Andres Freund wrote:
>> > The issue isn't there without the feature, because we (should) never
>> > access a tuple/detoast a column when it's invisible enough for the
>> > corresponding toast tuple to be vacuumed away. But with
>> > old_snapshot_timeout that's obv
On 2016-06-16 12:02:39 -0400, Robert Haas wrote:
> On Thu, Jun 16, 2016 at 11:37 AM, Andres Freund wrote:
> >> If that were really true, why would we not have the problem in
> >> current production versions that the toast table could be vacuumed
> >> before the heap, leading to exactly the issue y
On Thu, Jun 16, 2016 at 11:37 AM, Andres Freund wrote:
>> If that were really true, why would we not have the problem in
>> current production versions that the toast table could be vacuumed
>> before the heap, leading to exactly the issue you are talking
>> about?
>
> The issue isn't there withou
On 2016-06-16 09:50:09 -0500, Kevin Grittner wrote:
> On Wed, Jun 15, 2016 at 8:57 PM, Andres Freund wrote:
>
> > The simplest version of the scenario I'm concerned about is that a tuple
> > in a tuple is *not* vacuumed, even though it's elegible to be removed
> > due to STO. If that tuple has to
On Wed, Jun 15, 2016 at 8:57 PM, Andres Freund wrote:
> The simplest version of the scenario I'm concerned about is that a tuple
> in a tuple is *not* vacuumed, even though it's elegible to be removed
> due to STO. If that tuple has toasted columns, it could be the that the
> toast table was inde
Kevin Grittner wrote:
> test=# -- connection 1
> analyze verbose t1; -- when run after threshold, STO error occurs
> INFO: analyzing "public.t1"
> INFO: "t1": scanned 45 of 45 pages, containing 8999 live rows and
> 1001 dead rows; 8999 rows in sample, 8999 estimated total rows
> ERROR: snapsho
On 2016-06-15 20:22:24 -0500, Kevin Grittner wrote:
> I'm not clear where you see this as being in any way different with
> STO. Above it seemed that you saw this as an issue related to
> ANALYZE. If there is not early pruning for the table being
> analyzed, nothing is at all different. If there
On Wed, Jun 15, 2016 at 5:34 PM, Andres Freund wrote:
> On 2016-06-15 16:58:25 -0500, Kevin Grittner wrote:
>> On Wed, Jun 15, 2016 at 3:25 PM, Andres Freund wrote:
>>> On 2016-06-15 14:24:58 -0500, Kevin Grittner wrote:
On Wed, Jun 15, 2016 at 2:20 PM, Andres Freund wrote:
> We mi
On 2016-06-15 16:58:25 -0500, Kevin Grittner wrote:
> On Wed, Jun 15, 2016 at 3:25 PM, Andres Freund wrote:
> > On 2016-06-15 14:24:58 -0500, Kevin Grittner wrote:
> >> On Wed, Jun 15, 2016 at 2:20 PM, Andres Freund wrote:
> >>
> >> > We might fetch a toast tuple which
> >> > since have been re-p
On Wed, Jun 15, 2016 at 2:40 PM, Alvaro Herrera
wrote:
> Kevin Grittner wrote:
>> On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera
>> wrote:
>
>> > We actually go quite some lengths to support this case, even when it's
>> > the opinion of many that we shouldn't. For example VACUUM doesn't try
>>
On Wed, Jun 15, 2016 at 3:25 PM, Andres Freund wrote:
> On 2016-06-15 14:24:58 -0500, Kevin Grittner wrote:
>> On Wed, Jun 15, 2016 at 2:20 PM, Andres Freund wrote:
>>
>> > We might fetch a toast tuple which
>> > since have been re-purposed for a datum of a different type.
>>
>> How would that ha
On 2016-06-15 14:24:58 -0500, Kevin Grittner wrote:
> On Wed, Jun 15, 2016 at 2:20 PM, Andres Freund wrote:
>
> > We might fetch a toast tuple which
> > since have been re-purposed for a datum of a different type.
>
> How would that happen?
Autovac vacuums toast and heap tables independently. O
On Wed, Jun 15, 2016 at 3:40 PM, Alvaro Herrera
wrote:
> Kevin Grittner wrote:
> > On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera
> > wrote:
>
> > > We actually go quite some lengths to support this case, even when it's
> > > the opinion of many that we shouldn't. For example VACUUM doesn't tr
On Wed, Jun 15, 2016 at 2:59 PM, Alvaro Herrera
wrote:
> Kevin Grittner wrote:
>> On Wed, Jun 15, 2016 at 1:50 PM, Robert Haas wrote:
>>
>> > The expression index case is the one to worry about; if there is a
>> > problem, that's where it is. What bothers me is that a function used
>> > in an ex
Kevin Grittner wrote:
> On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera
> wrote:
> > We actually go quite some lengths to support this case, even when it's
> > the opinion of many that we shouldn't. For example VACUUM doesn't try
> > to find index entries using the values in each deleted tuple;
On Wed, Jun 15, 2016 at 2:20 PM, Andres Freund wrote:
> We might fetch a toast tuple which
> since have been re-purposed for a datum of a different type.
How would that happen?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-committers m
On 2016-06-15 14:50:46 -0400, Robert Haas wrote:
> On Wed, Jun 15, 2016 at 2:45 PM, Alvaro Herrera
> wrote:
> > Robert Haas wrote:
> >> On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner
> >> wrote:
> >> > The test I showed creates a situation which (to ANALYZE) is
> >> > identical to what you descr
On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera
wrote:
> Kevin Grittner wrote:
>> On Wed, Jun 15, 2016 at 1:50 PM, Robert Haas wrote:
>>
>>> The expression index case is the one to worry about; if there is a
>>> problem, that's where it is. What bothers me is that a function used
>>> in an expre
On Wed, Jun 15, 2016 at 1:54 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> The expression index case is the one to worry about; if there is a
>> problem, that's where it is. What bothers me is that a function used
>> in an expression index could do anything at all - it can read any
>> table
Kevin Grittner wrote:
> On Wed, Jun 15, 2016 at 1:50 PM, Robert Haas wrote:
>
> > The expression index case is the one to worry about; if there is a
> > problem, that's where it is. What bothers me is that a function used
> > in an expression index could do anything at all - it can read any
> >
On Wed, Jun 15, 2016 at 1:50 PM, Robert Haas wrote:
> The expression index case is the one to worry about; if there is a
> problem, that's where it is. What bothers me is that a function used
> in an expression index could do anything at all - it can read any
> table in the database.
It *can*,
Robert Haas wrote:
> On Wed, Jun 15, 2016 at 2:45 PM, Alvaro Herrera
> wrote:
> > Maybe it is possible to get into trouble if you're taking a sample for
> > an expression index.
>
> The expression index case is the one to worry about; if there is a
> problem, that's where it is. What bothers me
On Wed, Jun 15, 2016 at 2:45 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner
>> wrote:
>> > The test I showed creates a situation which (to ANALYZE) is
>> > identical to what you describe -- ANALYZE sees a page with an LSN
>> > recent enough that
On Wed, Jun 15, 2016 at 1:45 PM, Alvaro Herrera
wrote:
> Maybe it is possible to get into trouble if you're taking a sample for
> an expression index.
Maybe -- if you are using a function for an index expression which
does an explicit SELECT against some database table rather than
only using val
Robert Haas wrote:
> On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner
> wrote:
> > The test I showed creates a situation which (to ANALYZE) is
> > identical to what you describe -- ANALYZE sees a page with an LSN
> > recent enough that it could have been (and actually has been)
> > pruned. Why wo
On Wed, Jun 15, 2016 at 1:29 PM, Robert Haas wrote:
> On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner
> wrote:>> So what happens in this scenario:
>>> 1. ANALYZE runs really slowly - maybe the user-defined function it's
>>> running for the expression index is extremely long-running.
>>> 2. Eventu
On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner
wrote:>> So what happens in this scenario:
>> 1. ANALYZE runs really slowly - maybe the user-defined function it's
>> running for the expression index is extremely long-running.
>> 2. Eventually, the snapshot for ANALYZE is older than the configured
On Wed, Jun 15, 2016 at 10:46 AM, Robert Haas wrote:
> On Sat, Jun 11, 2016 at 11:29 AM, Kevin Grittner wrote:
>> I have reviewed the code and run tests to try to find something
>> here which could be considered a bug, without finding any problem.
>> When reading pages for the random sample for A
On Sat, Jun 11, 2016 at 11:29 AM, Kevin Grittner wrote:
> I have reviewed the code and run tests to try to find something
> here which could be considered a bug, without finding any problem.
> When reading pages for the random sample for ANALYZE (or
> auto-analyze) there is not an age check; so AN
On Tue, May 24, 2016 at 4:10 PM, Robert Haas wrote:
> On Tue, May 24, 2016 at 3:48 PM, Kevin Grittner wrote:
>> On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote:
>>> On 2016-05-24 11:24:44 -0500, Kevin Grittner wrote:
On Fri, May 6, 2016 at 8:28 PM, Kevin Grittner wrote:
> On Fri,
On Fri, Jun 10, 2016 at 10:26 AM, Robert Haas wrote:
> On Fri, Jun 10, 2016 at 10:45 AM, Kevin Grittner wrote:
>> Since vacuum calls the pruning function, and not the other way
>> around, the name you suggest would be technically more correct.
>> Committed using "Pruning" instead of "Vacuum" in
On Fri, Jun 10, 2016 at 10:45 AM, Kevin Grittner wrote:
> On Thu, Jun 9, 2016 at 6:16 PM, Robert Haas wrote:
>
>> So I like the idea of centralizing checks in
>> RelationAllowsEarlyVacuum, but shouldn't it really be called
>> RelationAllowsEarlyPruning?
>
> Since vacuum calls the pruning function
On Thu, Jun 9, 2016 at 6:16 PM, Robert Haas wrote:
> So I like the idea of centralizing checks in
> RelationAllowsEarlyVacuum, but shouldn't it really be called
> RelationAllowsEarlyPruning?
Since vacuum calls the pruning function, and not the other way
around, the name you suggest would be tech
On Thu, Jun 9, 2016 at 10:28 AM, Kevin Grittner wrote:
> [Thanks to Robert to stepping up to keep this moving while I was
> down yesterday with a minor injury. I'm back on it today.]
>> Generally, I think I see the hazard you're concerned about: I had
>> failed to realize, as you mentioned upthre
[Thanks to Robert to stepping up to keep this moving while I was
down yesterday with a minor injury. I'm back on it today.]
On Wed, Jun 8, 2016 at 3:11 PM, Robert Haas wrote:
> On Wed, Jun 8, 2016 at 4:04 PM, Kevin Grittner wrote:
>> -- connection 1
>> drop table if exists t1;
>> create table
On Fri, Jun 03, 2016 at 04:29:40PM -0500, Kevin Grittner wrote:
> On Fri, May 27, 2016 at 10:35 AM, Kevin Grittner wrote:
> > On Tue, May 24, 2016 at 4:10 PM, Robert Haas wrote:
>
> >> [ANALYZE of index with expression may fail to update statistics
> >> if ANALYZE runs longer than old_snapshot_t
On Wed, Jun 8, 2016 at 4:04 PM, Kevin Grittner wrote:
> On Wed, Jun 8, 2016 at 2:49 PM, Robert Haas wrote:
>> Do you have a test case that demonstrates a problem, or an explanation
>> of why you think there is one?
>
> With old_snapshot_threshold = '1min'
>
> -- connection 1
> drop table if exist
On Wed, Jun 8, 2016 at 2:49 PM, Robert Haas wrote:
> Do you have a test case that demonstrates a problem, or an explanation
> of why you think there is one?
With old_snapshot_threshold = '1min'
-- connection 1
drop table if exists t1;
create table t1 (c1 int not null);
insert into t1 select gen
On Wed, Jun 8, 2016 at 9:40 AM, Kevin Grittner wrote:
>>> Of course, ii_BrokenHotChain should be renamed to something like
>>> ii_UnsafeForOldSnapshots, and some comments need to be updated; but
>>> the above is the substance of it.
>>
>> I don't know why we'd want to rename it like that...
>
> If
On Tue, Jun 7, 2016 at 10:40 AM, Robert Haas wrote:
> On Sat, Jun 4, 2016 at 4:21 PM, Kevin Grittner wrote:
>> the minimal patch to fix behavior in this area would be:
>>
>> diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c
>> index 31a1438..6c379da 100644
>> --- a/src/backe
On Sat, Jun 4, 2016 at 4:21 PM, Kevin Grittner wrote:
> On Fri, Jun 3, 2016 at 4:24 PM, Kevin Grittner wrote:
>> Consequently, causing the index to be ignored in planning when
>> using the old index
>
> That last line should have read "using an old snapshot"
>
>> is not a nice optimization, but n
On Fri, Jun 3, 2016 at 4:24 PM, Kevin Grittner wrote:
> Consequently, causing the index to be ignored in planning when
> using the old index
That last line should have read "using an old snapshot"
> is not a nice optimization, but necessary for
> correctness. We already have logic to do this f
On Fri, May 27, 2016 at 10:35 AM, Kevin Grittner wrote:
> On Tue, May 24, 2016 at 4:10 PM, Robert Haas wrote:
>> [ANALYZE of index with expression may fail to update statistics
>> if ANALYZE runs longer than old_snapshot_threshold]
>> If we can get away with it, it would be a rather large win t
On Fri, May 27, 2016 at 10:18 AM, Kevin Grittner wrote:
> On Fri, May 27, 2016 at 9:58 AM, Kevin Grittner wrote:
>> On Tue, May 24, 2016 at 4:56 PM, Andres Freund wrote:
>
>>> If an old session with >= repeatable read accesses a clustered
>>> table (after the cluster committed), they'll now not
On Tue, May 31, 2016 at 10:03 AM, Robert Haas wrote:
> On Fri, May 27, 2016 at 10:58 AM, Kevin Grittner wrote:
>>> As far as I can see normal index builds will allow concurrent hot
>>> prunes and everything; since those only require page-level
>>> exclusive locks.
>>>
>>> So for !concurrent build
On Fri, May 27, 2016 at 10:58 AM, Kevin Grittner wrote:
>> As far as I can see normal index builds will allow concurrent hot
>> prunes and everything; since those only require page-level
>> exclusive locks.
>>
>> So for !concurrent builds we might end up with a corrupt index.
>
> ... by which you
On Tue, May 24, 2016 at 4:10 PM, Robert Haas wrote:
> On Tue, May 24, 2016 at 3:48 PM, Kevin Grittner wrote:
>> On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote:
>>> On 2016-05-24 11:24:44 -0500, Kevin Grittner wrote:
On Fri, May 6, 2016 at 8:28 PM, Kevin Grittner wrote:
> On Fri,
On Fri, May 27, 2016 at 9:58 AM, Kevin Grittner wrote:
> On Tue, May 24, 2016 at 4:56 PM, Andres Freund wrote:
>> If an old session with >= repeatable read accesses a clustered
>> table (after the cluster committed), they'll now not see any
>> errors, because all the LSNs look new.
>
> Again, it
On Tue, May 24, 2016 at 4:56 PM, Andres Freund wrote:
> The LSNs of the created index pages will be new, and we'll thus
> not necessarily error out when requried.
It is *old* LSNs that are *safe* -- *new* LSNs are what trigger the
"snapshot too old" error. So your observation may be a reason th
On 2016-05-24 16:09:27 -0500, Kevin Grittner wrote:
> On Tue, May 24, 2016 at 3:54 PM, Andres Freund wrote:
>
> > what about e.g. concurrent index builds? E.g. IndexBuildHeapRangeScan()
> > doesn't
> > seem to contain any checks against outdated blocks
>
> Why would it? We're talking about block
On Tue, May 24, 2016 at 4:09 PM, Kevin Grittner wrote:
> On Tue, May 24, 2016 at 3:54 PM, Andres Freund wrote:
>> It appears that concurrent index builds are currently broken
>> from a quick skim?
>
> Either you don't understand this feature very well, or I don't
> understand concurrent index bu
On Tue, May 24, 2016 at 4:10 PM, Robert Haas wrote:
> For purposes of
> "snapshot too old", though, it will be important that a function in an
> index which tries to read data from some other table which has been
> pruned cancels itself when necessary.
Hm. I'll try to work up a test case for th
On Tue, May 24, 2016 at 3:48 PM, Kevin Grittner wrote:
> On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote:
>> On 2016-05-24 11:24:44 -0500, Kevin Grittner wrote:
>>> On Fri, May 6, 2016 at 8:28 PM, Kevin Grittner wrote:
On Fri, May 6, 2016 at 7:48 PM, Andres Freund wrote:
>>>
> Th
On Tue, May 24, 2016 at 3:54 PM, Andres Freund wrote:
> what about e.g. concurrent index builds? E.g. IndexBuildHeapRangeScan()
> doesn't
> seem to contain any checks against outdated blocks
Why would it? We're talking about blocks where there were dead
tuples, with the transaction which updat
On 2016-05-24 14:48:35 -0500, Kevin Grittner wrote:
> On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote:
> > On 2016-05-24 11:24:44 -0500, Kevin Grittner wrote:
> >> On Fri, May 6, 2016 at 8:28 PM, Kevin Grittner wrote:
> >>> On Fri, May 6, 2016 at 7:48 PM, Andres Freund wrote:
> >>
> T
Kevin Grittner wrote:
> On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote:
> > On 2016-05-24 11:24:44 -0500, Kevin Grittner wrote:
> >> On Fri, May 6, 2016 at 8:28 PM, Kevin Grittner wrote:
> >>> On Fri, May 6, 2016 at 7:48 PM, Andres Freund wrote:
> >>
> That comment reminds me of a qu
On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote:
> On 2016-05-24 11:24:44 -0500, Kevin Grittner wrote:
>> On Fri, May 6, 2016 at 8:28 PM, Kevin Grittner wrote:
>>> On Fri, May 6, 2016 at 7:48 PM, Andres Freund wrote:
>>
That comment reminds me of a question I had: Did you consider the
On 2016-05-24 13:04:09 -0500, Kevin Grittner wrote:
> On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote:
>
> > Analyze IIRC acquires a new snapshot when getting sample rows,
>
> I could not find anything like that, and a case-insensitive search
> of analyze.c finds no occurrences of "snap".
Kevin Grittner wrote:
> On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote:
>
> > Analyze IIRC acquires a new snapshot when getting sample rows,
>
> I could not find anything like that, and a case-insensitive search
> of analyze.c finds no occurrences of "snap". Can you remember
> where you
Kevin Grittner writes:
> On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote:
>> Analyze IIRC acquires a new snapshot when getting sample rows,
> I could not find anything like that, and a case-insensitive search
> of analyze.c finds no occurrences of "snap". Can you remember
> where you thin
On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote:
> Analyze IIRC acquires a new snapshot when getting sample rows,
I could not find anything like that, and a case-insensitive search
of analyze.c finds no occurrences of "snap". Can you remember
where you think you saw something that would c
On 2016-05-24 11:24:44 -0500, Kevin Grittner wrote:
> On Fri, May 6, 2016 at 8:28 PM, Kevin Grittner wrote:
> > On Fri, May 6, 2016 at 7:48 PM, Andres Freund wrote:
>
> >> That comment reminds me of a question I had: Did you consider the effect
> >> of this patch on analyze? It uses a snapshot,
On Fri, May 6, 2016 at 8:28 PM, Kevin Grittner wrote:
> On Fri, May 6, 2016 at 7:48 PM, Andres Freund wrote:
>> That comment reminds me of a question I had: Did you consider the effect
>> of this patch on analyze? It uses a snapshot, and by memory you've not
>> built in a defense against analyze
On 2016-05-06 20:28:27 -0500, Kevin Grittner wrote:
> On Fri, May 6, 2016 at 7:48 PM, Andres Freund wrote:
> > On 2016-05-06 19:43:24 -0500, Kevin Grittner wrote:
> >> It's disappointing that I am not getting more consistent numbers,
> >> but NUMA can be hard to manage that way.
> >
> > FWIW, in m
On Fri, May 6, 2016 at 7:48 PM, Andres Freund wrote:
> On 2016-05-06 19:43:24 -0500, Kevin Grittner wrote:
>> It's disappointing that I am not getting more consistent numbers,
>> but NUMA can be hard to manage that way.
>
> FWIW, in my experience, unless you disable autovacuum (or rather
> auto-an
On 2016-05-06 19:43:24 -0500, Kevin Grittner wrote:
> It's disappointing that I am not getting more consistent numbers,
> but NUMA can be hard to manage that way.
FWIW, in my experience, unless you disable autovacuum (or rather
auto-analyze), the effects from non-predicable analyze runs with
long-
On Fri, May 6, 2016 at 5:07 PM, Andres Freund wrote:
> On 2016-05-06 14:18:22 -0500, Kevin Grittner wrote:
>> I rebased the patch Ants posted (attached), and am running
>> benchmarks on a cthulhu (a big NUMA machine with 8 memory nodes).
>> Normally I wouldn't post results without a lot more data
Hi,
On 2016-05-06 14:18:22 -0500, Kevin Grittner wrote:
> I rebased the patch Ants posted (attached), and am running
> benchmarks on a cthulhu (a big NUMA machine with 8 memory nodes).
> Normally I wouldn't post results without a lot more data points
> with multiple samples at each, but the initia
On Wed, Apr 20, 2016 at 8:08 PM, Ants Aasma wrote:
> I had an idea I wanted to test out. The gist of it is to effectively
> have the last slot of timestamp to xid map stored in the latest_xmin
> field and only update the mapping when slot boundaries are crossed.
> See attached WIP patch for detai
On Tue, Apr 19, 2016 at 8:41 PM, Kevin Grittner wrote:
>
> On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila
wrote:
> > On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund
wrote:
> >>
> >> On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
> >> > That is more controversial than the potential ~2% regression f
On Thu, Apr 21, 2016 at 6:38 AM, Ants Aasma wrote:
>
> On Tue, Apr 19, 2016 at 6:11 PM, Kevin Grittner wrote:
> > On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila
wrote:
> >> On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund
wrote:
> >>>
> >>> FWIW, I could be kinda convinced that it's temporarily ok,
On Wed, Apr 20, 2016 at 7:39 PM, Andres Freund wrote:
>
> On 2016-04-19 20:27:31 +0530, Amit Kapila wrote:
> > On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund
wrote:
> > >
> > > On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
> > > > That is more controversial than the potential ~2% regression for
On Thu, Apr 21, 2016 at 2:10 PM, Ants Aasma wrote:
> On Thu, Apr 21, 2016 at 5:16 PM, Kevin Grittner wrote:
>> Could you provide enough to make that a self-contained
>> reproducible test case [?]
> [provided]
Thanks! I have your test case running, and it is not immediately
clear why old rows
On Thu, Apr 21, 2016 at 5:16 PM, Kevin Grittner wrote:
> On Wed, Apr 20, 2016 at 8:08 PM, Ants Aasma wrote:
>
>> However, while checking out if my proof of concept patch actually
>> works I hit another issue. I couldn't get my test for the feature to
>> actually work. The test script I used is at
On Wed, Apr 20, 2016 at 8:08 PM, Ants Aasma wrote:
> However, while checking out if my proof of concept patch actually
> works I hit another issue. I couldn't get my test for the feature to
> actually work. The test script I used is attached.
Could you provide enough to make that a self-containe
On Tue, Apr 19, 2016 at 6:11 PM, Kevin Grittner wrote:
> On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila wrote:
>> On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund wrote:
>>>
>>> On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
>>> > That is more controversial than the potential ~2% regression for
>>>
On 2016-04-19 20:27:31 +0530, Amit Kapila wrote:
> On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund wrote:
> >
> > On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
> > > That is more controversial than the potential ~2% regression for
> > > old_snapshot_threshold=-1. Alvaro[2] and Robert[3] are okay
On Tue, Apr 19, 2016 at 8:44 PM, Robert Haas wrote:
>
> On Tue, Apr 19, 2016 at 11:11 AM, Kevin Grittner
wrote:
> > On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila
wrote:
>
> >> It seems that for read-only workloads, MaintainOldSnapshotTimeMapping()
> >> takes EXCLUSIVE LWLock which seems to be a p
On Tue, Apr 19, 2016 at 10:14 AM, Robert Haas wrote:
> On Tue, Apr 19, 2016 at 11:11 AM, Kevin Grittner wrote:
>> On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila wrote:
>>> On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund wrote:
On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
> That i
On Tue, Apr 19, 2016 at 11:11 AM, Kevin Grittner wrote:
> On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila wrote:
>> On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund wrote:
>>>
>>> On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
>>> > That is more controversial than the potential ~2% regression for
>>
On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila wrote:
> On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund wrote:
>>
>> On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
>> > That is more controversial than the potential ~2% regression for
>> > old_snapshot_threshold=-1. Alvaro[2] and Robert[3] are okay
On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund wrote:
>
> On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
> > That is more controversial than the potential ~2% regression for
> > old_snapshot_threshold=-1. Alvaro[2] and Robert[3] are okay releasing
> > that way, and Andres[4] is not.
>
> FWIW, I
> Second, I don't think it will improve and become performant without
> exposure to a wider audience.
Huh? The issue is a relatively simple to spot architectural issue
(taking a single exclusive lock during snapshot acquiration which only
needs shared locks otherwise) - I don't see how any input i
On 4/16/16 4:44 PM, Noah Misch wrote:
> The key judgment to finalize here is whether it's okay to release this feature
> given its current effect[1], when enabled, on performance. That is more
> controversial than the potential ~2% regression for old_snapshot_threshold=-1.
> Alvaro[2] and Robert[
On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
> That is more controversial than the potential ~2% regression for
> old_snapshot_threshold=-1. Alvaro[2] and Robert[3] are okay releasing
> that way, and Andres[4] is not.
FWIW, I could be kinda convinced that it's temporarily ok, if there'd be
a c
On Wed, Apr 13, 2016 at 03:21:31PM -0500, Kevin Grittner wrote:
> If 2201d801 was not included in your -1 tests, have you identified
> where the 2% extra run time is going on -1 versus reverted? Since
> several other threads lately have reported bigger variation than
> that based on random memory
On Thu, Apr 14, 2016 at 12:23 AM, Andres Freund wrote:
> On 2016-04-13 16:05:25 -0500, Kevin Grittner wrote:
> > OK, thanks. I can't think of anything else to ask for at this
> > point. If you feel that you have enough to press for some
> > particular course of action, go for it.
>
> I think we
1 - 100 of 122 matches
Mail list logo
