On Tue, 22 Nov 2022 at 18:44, Tom Lane wrote:
>
> I wrote:
> > Still wondering if there's really no CHECK_FOR_INTERRUPT anywhere
> > else in this loop.
>
> I did some experimentation using the test case Jakub presented
> to start with, and verified that that loop does respond promptly
> to
On Tue, Nov 22, 2022 at 1:44 PM Tom Lane wrote:
> I wrote:
> > Still wondering if there's really no CHECK_FOR_INTERRUPT anywhere
> > else in this loop.
>
> I did some experimentation using the test case Jakub presented
> to start with, and verified that that loop does respond promptly
> to
I wrote:
> Still wondering if there's really no CHECK_FOR_INTERRUPT anywhere
> else in this loop.
I did some experimentation using the test case Jakub presented
to start with, and verified that that loop does respond promptly
to control-C even in HEAD. So there are CFI(s) in the loop as
I
Robert Haas writes:
> On Tue, Nov 22, 2022 at 11:35 AM Tom Lane wrote:
>> Is it appropriate to count distinct pages, rather than just the
>> number of times we have to visit a heap tuple? That seems to
>> complicate the logic a good deal, and I'm not sure it's buying
>> much, especially since
On Tue, Nov 22, 2022 at 11:35 AM Tom Lane wrote:
> Simon Riggs writes:
> > New patch version reporting for duty, sir. Please take it from here!
>
> Why the CHECK_FOR_INTERRUPTS? I'd supposed that there's going to be
> one somewhere down inside the index or heap access --- do you have
> reason
Simon Riggs writes:
> New patch version reporting for duty, sir. Please take it from here!
Why the CHECK_FOR_INTERRUPTS? I'd supposed that there's going to be
one somewhere down inside the index or heap access --- do you have
reason to think there isn't?
Is it appropriate to count distinct
On Mon, 21 Nov 2022 at 20:55, Robert Haas wrote:
>
> On Mon, Nov 21, 2022 at 1:17 PM Andres Freund wrote:
> > On November 21, 2022 9:37:34 AM PST, Robert Haas
> > wrote:
> > >On Mon, Nov 21, 2022 at 12:30 PM Andres Freund wrote:
> > >> This can't quite be right - isn't this only applying the
On Mon, 21 Nov 2022 at 22:15, Tom Lane wrote:
>
> Andres Freund writes:
> > On 2022-11-21 16:17:56 -0500, Robert Haas wrote:
> >> But ... what if they're not? Could the index contain a large number of
> >> pages containing just 1 tuple each, or no tuples at all? If so, maybe
> >> we can read ten
On Mon, 21 Nov 2022 at 23:34, Robert Haas wrote:
>
> On Mon, Nov 21, 2022 at 6:17 PM Tom Lane wrote:
> > evidence that it's a live problem. API warts are really hard to
> > get rid of once instituted.
>
> Yeah, agreed.
Agreed, happy not to; that version was just a WIP to see how it might work.
Hi all,
apologies the patch was rushed too quickly - my bad. I'm attaching a
fixed one as v0004 (as it is the 4th patch floating around here).
-Jakub Wartak
On Mon, Nov 21, 2022 at 9:55 PM Robert Haas wrote:
>
> On Mon, Nov 21, 2022 at 1:17 PM Andres Freund wrote:
> > On November 21, 2022
On Mon, Nov 21, 2022 at 6:17 PM Tom Lane wrote:
> evidence that it's a live problem. API warts are really hard to
> get rid of once instituted.
Yeah, agreed.
--
Robert Haas
EDB: http://www.enterprisedb.com
Robert Haas writes:
> On Mon, Nov 21, 2022 at 5:15 PM Tom Lane wrote:
>> I think we should content ourselves with improving the demonstrated
>> case, which is where we're forced to do a lot of heap fetches due
>> to lots of not-all-visible tuples.
> All right. I've been bitten by this problem
On Mon, Nov 21, 2022 at 5:15 PM Tom Lane wrote:
> I think we should content ourselves with improving the demonstrated
> case, which is where we're forced to do a lot of heap fetches due
> to lots of not-all-visible tuples. Whether we can spend a lot of
> time scanning the index without ever
Andres Freund writes:
> On 2022-11-21 16:17:56 -0500, Robert Haas wrote:
>> But ... what if they're not? Could the index contain a large number of
>> pages containing just 1 tuple each, or no tuples at all? If so, maybe
>> we can read ten bazillion index pages trying to find each heap tuple
>>
Hi,
On 2022-11-21 16:17:56 -0500, Robert Haas wrote:
> But ... what if they're not? Could the index contain a large number of
> pages containing just 1 tuple each, or no tuples at all? If so, maybe
> we can read ten bazillion index pages trying to find each heap tuple
> and still end up in
On Mon, Nov 21, 2022 at 2:15 PM Tom Lane wrote:
> Andres Freund writes:
> > On November 21, 2022 10:44:17 AM PST, Simon Riggs
> > wrote:
> >> Robert, something like this perhaps? limit on both the index and the heap.
>
> > I don't think we should add additional code / struct members into very
On Mon, Nov 21, 2022 at 1:17 PM Andres Freund wrote:
> On November 21, 2022 9:37:34 AM PST, Robert Haas
> wrote:
> >On Mon, Nov 21, 2022 at 12:30 PM Andres Freund wrote:
> >> This can't quite be right - isn't this only applying the limit if we found
> >> a
> >> visible tuple?
> >
> >It
Andres Freund writes:
> On November 21, 2022 10:44:17 AM PST, Simon Riggs
> wrote:
>> Robert, something like this perhaps? limit on both the index and the heap.
> I don't think we should add additional code / struct members into very common
> good paths for these limits.
Yeah, I don't like
Hi,
On November 21, 2022 10:44:17 AM PST, Simon Riggs
wrote:
>Robert, something like this perhaps? limit on both the index and the heap.
I don't think we should add additional code / struct members into very common
good paths for these limits.
I don't really understand the point of
On Mon, 21 Nov 2022 at 18:17, Andres Freund wrote:
>
> Hi,
>
> On November 21, 2022 9:37:34 AM PST, Robert Haas
> wrote:
> >On Mon, Nov 21, 2022 at 12:30 PM Andres Freund wrote:
> >> This can't quite be right - isn't this only applying the limit if we found
> >> a
> >> visible tuple?
> >
>
Hi,
On November 21, 2022 9:37:34 AM PST, Robert Haas wrote:
>On Mon, Nov 21, 2022 at 12:30 PM Andres Freund wrote:
>> This can't quite be right - isn't this only applying the limit if we found a
>> visible tuple?
>
>It doesn't look that way to me, but perhaps I'm just too dense to see
>the
Robert Haas writes:
> On Mon, Nov 21, 2022 at 12:38 PM Tom Lane wrote:
>> What it's restricting is the number of heap page fetches, which
>> might be good enough. We don't have a lot of visibility here
>> into how many index pages were scanned before returning the next
>> not-dead index entry,
On Mon, Nov 21, 2022 at 12:38 PM Tom Lane wrote:
> Andres Freund writes:
> > This can't quite be right - isn't this only applying the limit if we found a
> > visible tuple?
>
> What it's restricting is the number of heap page fetches, which
> might be good enough. We don't have a lot of
Andres Freund writes:
> This can't quite be right - isn't this only applying the limit if we found a
> visible tuple?
What it's restricting is the number of heap page fetches, which
might be good enough. We don't have a lot of visibility here
into how many index pages were scanned before
On Mon, Nov 21, 2022 at 12:30 PM Andres Freund wrote:
> This can't quite be right - isn't this only applying the limit if we found a
> visible tuple?
It doesn't look that way to me, but perhaps I'm just too dense to see
the problem?
--
Robert Haas
EDB: http://www.enterprisedb.com
This patch version runs "continue" unconditionally (rather than
conditionally, like the previous version).
if (!index_fetch_heap(index_scan, tableslot))
continue; /* no visible tuple,
try next index entry */
Hi,
On 2022-11-21 17:06:16 +0100, Jakub Wartak wrote:
> @@ -6213,14 +6216,26 @@ get_actual_variable_endpoint(Relation heapRel,
> /* Fetch first/next tuple in specified direction */
> while ((tid = index_getnext_tid(index_scan, indexscandir)) != NULL)
> {
> +
Hi,
Draft version of the patch attached (it is based on Simon's)
I would be happier if we could make that #define into GUC (just in
case), although I do understand the effort to reduce the number of
various knobs (as their high count causes their own complexity).
-Jakub Wartak.
On Mon, Nov 21,
On Mon, Nov 21, 2022 at 10:32 AM Tom Lane wrote:
> Robert Haas writes:
> > Is there any reason to tie this into page costs? I'd be more inclined
> > to just make it a hard limit on the number of pages. I think that
> > would be more predictable and less prone to surprising (bad) behavior.
>
>
Robert Haas writes:
> Is there any reason to tie this into page costs? I'd be more inclined
> to just make it a hard limit on the number of pages. I think that
> would be more predictable and less prone to surprising (bad) behavior.
Agreed, a simple limit of N pages fetched seems appropriate.
>
On Mon, 21 Nov 2022 at 15:23, Robert Haas wrote:
>
> On Mon, Nov 21, 2022 at 10:14 AM Simon Riggs
> wrote:
> > > > What we need is a solution that avoids reading an unbounded number of
> > > > tuples under any circumstances. I previously suggested using
> > > > SnapshotAny here, but Tom didn't
On Mon, Nov 21, 2022 at 10:14 AM Simon Riggs
wrote:
> > > What we need is a solution that avoids reading an unbounded number of
> > > tuples under any circumstances. I previously suggested using
> > > SnapshotAny here, but Tom didn't like that. I'm not sure if there are
> > > safety issues there
On Mon, 21 Nov 2022 at 15:01, Tom Lane wrote:
>
> > What we need is a solution that avoids reading an unbounded number of
> > tuples under any circumstances. I previously suggested using
> > SnapshotAny here, but Tom didn't like that. I'm not sure if there are
> > safety issues there or if Tom
Robert Haas writes:
> I don't think this is safe at all. Wait events can only bracket
> individual operations, like the reads of the individual index blocks,
> not report on which phase of a larger operation is in progress. If we
> try to make them do the latter, we will have a hot mess on our
On Mon, Nov 21, 2022 at 7:22 AM Alvaro Herrera wrote:
> On 2022-Nov-21, Jakub Wartak wrote:
> > b) I was wondering about creating a new wait class "Planner" with the
> > event "ReadingMinMaxIndex" (or similar). The obvious drawback is the
> > naming/categorization as wait events are ... well.. as
On 2022-Nov-21, Jakub Wartak wrote:
> b) I was wondering about creating a new wait class "Planner" with the
> event "ReadingMinMaxIndex" (or similar). The obvious drawback is the
> naming/categorization as wait events are ... well.. as the name "WAIT"
> implies, while those btree lookups could
Hi hackers,
the case of planner's
src/backend/utils/adt/selfuncs.c:get_actual_variable_endpoint()
spending literally seconds seems to be well known fact across hackers
(in the extreme wild case it can be over 1+ hour on VLDBs). For those
unfamiliar it is planner estimation that tries to read real
37 matches
Mail list logo
