On Fri, 8 Oct 2021 at 20:01, David Fetter wrote:
> On Sat, Sep 22, 2018 at 06:53:55PM +1200, Edmund Horner wrote:
> > Hi all,
> >
> > Here are some rebased versions of the last two patches. No changes in
> > functionality, except a minor case sensitivity fix in the &
On Mon, 7 Jun 2021 at 22:11, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> This patch didn't add _outTidRangePath() even though we have outNode()
> coverage for most/all path nodes. Was this just forgotten? See
> attached patch.
>
Yes, it looks like an omission. Thanks for spo
On Fri, 1 Jan 2021 at 14:30, David Fetter wrote:
> On Sun, Dec 01, 2019 at 11:34:16AM +0900, Michael Paquier wrote:
> > Okay, still nothing has happened after two months. Once this is
> > solved a new patch submission could be done. For now I have marked
> > the entry as returned with feedback.
On Wed, 4 Sep 2019 at 10:34, Alvaro Herrera wrote:
>
> On 2019-Aug-01, Edmund Horner wrote:
>
> > Hi everyone,
> >
> > Sadly it is the end of the CF and I have not had much time to work on
> > this. I'll probably get some time in the next month to look at
On Thu, 1 Aug 2019 at 17:47, Thomas Munro wrote:
> On Thu, Aug 1, 2019 at 5:34 PM Edmund Horner wrote:
> > Should we move to CF? We have been in the CF cycle for almost a year now...
>
> Hi Edmund,
>
> No worries, that's how it goes sometimes. Please move it to
On Mon, 22 Jul 2019 at 19:44, Edmund Horner wrote:
> On Mon, 22 Jul 2019 at 19:25, David Rowley
> > On Sat, 20 Jul 2019 at 06:21, Andres Freund wrote:
> > > Yea, I was thinking of something like 2. We already have a few extra
> > > types of scan nodes (bitmap heap an
On Mon, 22 Jul 2019 at 19:25, David Rowley
> On Sat, 20 Jul 2019 at 06:21, Andres Freund wrote:
> > Yea, I was thinking of something like 2. We already have a few extra
> > types of scan nodes (bitmap heap and sample scan), it'd not be bad to
> > add another. And as you say, they can just share
vid Rowley wrote:
>
> On Mon, 15 Jul 2019 at 17:54, Edmund Horner wrote:
> > Summary of changes compared to last time:
> > - I've added the additional "scan_setlimits" table AM method. To
> > check whether it's implemented in the planner, I hav
On Thu, 11 Jul 2019 at 10:22, David Rowley wrote:
> So it seems that the plan is to insist that TIDs are tuple identifiers
> for all table AMs, for now. If that changes in the future, then so be
> it, but I don't think that's cause for delaying any work on TID Range
> Scans. Also from scanning a
On Thu, 11 Jul 2019 at 10:22, David Rowley wrote:
> > A. Continue to target only heapam tables, making the bare minimum
> > changes necessary for the new tableam api.
> > B. Try to do something more general that works on all tableam
> > implementations for which it may be useful.
>
> Going by th
On Thu, 4 Jul 2019 at 15:43, David Rowley wrote:
> On Mon, 1 Jul 2019 at 23:29, Thomas Munro wrote:
> > The new CF is here. I'm going through poking threads for submissions
> > that don't apply, but it sounds like this needs more than a rebase?
> > Perhaps this belongs in the next CF?
>
> 0001 a
On Tue, 26 Mar 2019 at 11:54, Tom Lane wrote:
>
> Andres Freund writes:
> > I was kinda hoping to keep block numbers out of the "main" APIs, to
> > avoid assuming everything is BLCKSZ based. I don't have a particular
> > problem allowing an optional setscanlimits type callback that works with
> >
On Sat, 23 Mar 2019 at 12:01, Hadi Moshayedi wrote:
> Yesterday while doing some tests, I noticed that the following doesn't work
> properly:
>
> create role test_role with login;
> create table ref(a int primary key);
> grant references on ref to test_role;
> set role test_role;
> create table t
On Fri, 15 Mar 2019 at 18:18, Chapman Flack wrote:
> What exactly is a savepointLevel?
>
> They seem to have been there for 15 years[1], diligently copied from
> parent transactions to children, fastidiously checked to avoid crossing
> a level on rollback or release, but does anything ever change
On Thu, 14 Mar 2019 at 23:37, Edmund Horner wrote:
> On Thu, 14 Mar 2019 at 23:06, David Rowley
> wrote:
> > Just looking again, I think the block of code starting:
> >
> > + if (density > 0.0)
> >
> > needs a comment to mention what it's doing. Per
On Thu, 14 Mar 2019 at 23:06, David Rowley wrote:
> On Thu, 14 Mar 2019 at 21:12, Edmund Horner wrote:
> > I'm not sure how an unreasonable underestimation would occur here. If
> > you have a table bloated to say 10x its minimal size, the estimator
> > still assum
On Thu, 14 Mar 2019 at 16:46, David Rowley wrote:
>
> The only possible risk I can foresee is that it may be more likely we
> underestimate the selectivity and that causes something like a nested
> loop join due to the estimation being, say 1 row.
>
> It could happen in a case like:
>
> SELECT * F
On Sat, 9 Feb 2019 at 04:48, Brandur Leach wrote:
> I've attached a patch that implements SortSupport for the
> inet/cidr types. It has the effect of typically reducing
> the time taken to sort these types by ~50-60% (as measured
> by `SELECT COUNT(DISTINCT ...)` which will carry over to
> common
On Sat, 19 Jan 2019 at 17:04, Edmund Horner wrote:
> On Sat, 19 Jan 2019 at 05:35, Tom Lane wrote:
>
>> Edmund Horner writes:
>> > My patch uses the same path type and executor for all extractable
>> tidquals.
>>
>> > This worked pretty well, but I am
Feb 2019 at 23:34, Andres Freund wrote:
> Hi,
>
> On 2019-01-19 17:04:13 +1300, Edmund Horner wrote:
> > On Sat, 19 Jan 2019 at 05:35, Tom Lane wrote:
> >
> > > Edmund Horner writes:
> > > > My patch uses the same path type and executor for all extracta
I added some code to selfuncs.c to estimate the selectivity of CTID,
including nullness, in my ongoing attempt to add TID range scans [1]. And
as Tom pointed out [2], no system attribute can be null, so we might as
well handle them all.
That's what the attached patch does.
I observed a few intere
On Sat, 19 Jan 2019 at 05:35, Tom Lane wrote:
> Edmund Horner writes:
> > My patch uses the same path type and executor for all extractable
> tidquals.
>
> > This worked pretty well, but I am finding it difficult to reimplement it
> in
> > the new tidpath.c code.
&
Hi all,
I am a bit stuck and I think it's best to try to explain where.
I'm still rebasing the patches for the changes Tom made to support
parameterised TID paths for joins. While the addition of join support
itself does not really touch the same code, the modernisation -- in
particular, returni
On Sat, 22 Dec 2018 at 07:10, Tom Lane wrote:
> BTW, with respect to this bit in 0001:
>
> @@ -1795,6 +1847,15 @@ nulltestsel(PlannerInfo *root, NullTestType
> nulltesttype, Node *arg,
> return (Selectivity) 0; /* keep compiler quiet */
> }
> }
> +else if (varda
On Sat, 22 Dec 2018 at 12:34, Tom Lane wrote:
> I decided to spend an afternoon seeing exactly how much work would be
> needed to support parameterized TID scans, ie nestloop-with-inner-TID-
> scan joins, as has been speculated about before, most recently here:
>
> https://www.postgresql.org/messa
On Fri, 21 Dec 2018 at 16:31, Tom Lane wrote:
>
> Edmund Horner writes:
> > For the forward scan, I seem to recall, from your merge join example,
> > that it's useful to set the pathkeys even when there are no
> > query_pathkeys. We just have to unconditionally se
On Fri, 21 Dec 2018 at 13:25, David Rowley wrote:
> On Fri, 21 Dec 2018 at 13:09, Edmund Horner wrote:
> > On Fri, 21 Dec 2018 at 11:21, Tom Lane wrote:
> > > I'm having a hard time wrapping my mind around why you'd bother with
> > > backwards TID scans.
On Fri, 21 Dec 2018 at 11:21, Tom Lane wrote:
>
> Edmund Horner writes:
> > [ tid scan patches ]
>
> I'm having a hard time wrapping my mind around why you'd bother with
> backwards TID scans. The amount of code needed versus the amount of
> usefulness seems li
On Thu, 22 Nov 2018 at 20:41, David Rowley wrote:
> I've now had a look over the latest patches and I've found a few more
> things. Many of these are a bit nitpicky, but certainly not all. I
> also reviewed 0004 this time.
Whew! A lot more things to look at.
I've tried to address most of what
On Sat, 24 Nov 2018 at 15:46, Tomas Vondra wrote:
> On 11/24/18 1:56 AM, Edmund Horner wrote:
> > On Fri, 23 Nov 2018 at 07:03, Tomas Vondra
> > wrote:
> >> On 11/22/18 8:41 AM, David Rowley wrote:
> >>> ...
> >>> 3. I'd rather se
On Fri, 23 Nov 2018 at 07:03, Tomas Vondra wrote:
> On 11/22/18 8:41 AM, David Rowley wrote:
> > ...
> > 3. I'd rather see EnsureTidRangeSpace() keep doubling the size of the
> > allocation until it reaches the required size. See how
> > MakeSharedInvalidMessagesArray() does it. Doing it this way
Hi, here's the new patch(s).
Mostly the same, but trying to address your comments from earlier as
well as clean up a few other things I noticed.
Cheers,
Edmund
On Fri, 9 Nov 2018 at 15:01, Edmund Horner wrote:
>
> On Tue, 6 Nov 2018 at 16:40, David Rowley
> wrote:
> > I&
On Tue, 6 Nov 2018 at 16:40, David Rowley wrote:
> I've been looking over 0001 to 0003. I ran out of steam before 0004.
Hi David, thanks for another big review with lots of improvements.
> I like the design of the new patch. From what I threw so far at the
> selectivity estimation code, it seems
On Wed, 7 Nov 2018 at 11:41, Thomas Munro wrote:
>
> Hello,
>
> PostgreSQL likes to probe the size of relations with lseek(SEEK_END) a
> lot. For example, a fully prewarmed pgbench -S transaction consists
> of recvfrom(), lseek(SEEK_END), lseek(SEEK_END), sendto(). I think
> lseek() is probably
On Tue, 6 Nov 2018 at 16:52, Alvaro Herrera wrote:
> On 2018-Nov-06, David Rowley wrote:
> > 14. we pass 'false' to what?
> >
> > + * save the tuple and the buffer returned to us by the access methods in
> > + * our scan tuple slot and return the slot. Note: we pass 'false' because
> > + * tuples
Hi all,
I have managed to split my changes into 4 patches:
v3-0001-Add-selectivity-and-nullness-estimates-for-the-ItemP.patch
v3-0002-Support-range-quals-in-Tid-Scan.patch
v3-0003-Support-backward-scans-over-restricted-ranges-in-hea.patch
v3-0004-Tid-Scan-results-are-ordered.patch
(1) is basical
David Rowley said:
> I believe that we should be delaying the PlannerInfo's
> total_table_pages calculation until after constraint exclusion and
> partition pruning have taken place. Doing this calculation before we
> determine which relations we don't need to scan can lead to
> incorrectly applyin
On Wed, 3 Oct 2018 at 17:36, David Rowley wrote:
> I know commit fest is over, but I made a pass of this to hopefully
> provide a bit of guidance so that it's closer for the November 'fest.
Hi David. Thanks for the review. It's fairly thorough and you must
have put some time into it -- I really
On Fri, 28 Sep 2018 at 17:02, Edmund Horner wrote:
> I did run pgindent over it though. :)
But I didn't check if it still applied to master. Sigh. Here's one that does.
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 3395445..e89343f 100
On Wed, 19 Sep 2018 at 18:56, David Rowley wrote:
>
> On 19 September 2018 at 18:04, Edmund Horner wrote:
> > I have been generally following this approach (handling more kinds of
> > TID comparisons), and have found myself doing things like pairing up >
> > with
David Rowley said:
> I believe that we should be delaying the PlannerInfo's
> total_table_pages calculation until after constraint exclusion and
> partition pruning have taken place. Doing this calculation before we
> determine which relations we don't need to scan can lead to
> incorrectly applyin
Hi all,
Here are some rebased versions of the last two patches. No changes in
functionality, except a minor case sensitivity fix in the "completion
after commas" patch.
Edmund
01-psql-select-tab-completion-v8.patch
Description: Binary data
02-select-completion-after-commas.patch
Description:
On Mon, 17 Sep 2018 at 23:21, David Rowley wrote:
> On 15 August 2018 at 11:11, Edmund Horner wrote:
>> So we'd extend that to:
>> - Include in the OR-list "range" subquals of the form (ctid > ? AND
>> ctid < ?) (either side could be optional, and we
On 12 August 2018 at 20:07, David Rowley wrote:
>> Since range scan execution is rather different from the existing
>> TidScan execution, I ended up making a new plan type, TidRangeScan.
>> There is still only one TidPath, but it has an additional member that
>> describes which method to use.
>
>
Hello,
To scratch an itch, I have been working on teaching TidScan how to do
range queries, i.e. those using >=, <, BETWEEN, etc. This means we
can write, for instance,
SELECT * FROM t WHERE ctid >= '(1000,0)' AND ctid < '(2000,0)';
instead of resorting to the old trick:
SELECT * FROM
On 17 July 2018 at 03:27, Joao De Almeida Pereira
wrote:
> After playing alittle bit around with the patch I noticed that a comma was
> missing in line 1214
> + 1202 /* min_server_version */
> + 1203 9,
> + 1204 /* catname */
> + 1205
On 17 July 2018 at 00:00, Heikki Linnakangas wrote:
> Playing around with this a little bit, I'm not very satisfied with the
> completions. Sometimes this completes too much, and sometimes too little.
> All of this has been mentioned in this and the other thread [1] already,
> this just my opinion
On 2 July 2018 at 17:57, C,C H wrote:
> I use tab-completion in psql quite often and I find that I can't complete
> "FROM" for SELECT query.
>
> So I try to create a patch for it.
>
> I download the source code from GitHub master branch and modify the file to
> create the patch.
>
> I compile the
On 29 May 2018 at 07:28, Vik Fearing wrote:
> The tab completion for the TABLE command includes indexes but that's a
> bug. Attached is a trivial patch to fix it.
Looks correct to me.
You lose tab completion for "TABLE pg_toast.pg_toast_xyz" but that
seems reasonable. If people want to query t
Hi,
While looking at Justin's patch for VACUUM completions, I found an
existing bit of code that tries to match on a word with a space:
/* Complete "CREATE PUBLICATION FOR TABLE " */
else if (Matches4("CREATE", "PUBLICATION", MatchAny, "FOR TABLE"))
COMPLETE_WITH_SCHEMA_QUERY(Quer
On 29 May 2018 at 12:06, Justin Pryzby wrote:
> Find attached tab completion for the following:
>
> "... Also, recursively perform VACUUM and ANALYZE on partitions when the
> command is applied to a partitioned table."
> 3c3bb99330aa9b4c2f6258bfa0265d806bf365c3
>
> Add parenthesized options syntax
On 6 April 2018 at 13:29, Peter Eisentraut
wrote:
> The selection of which functions to show can be further refined.
>
> I don't think the contents of pg_amproc and pg_cast should be excluded.
> Some of those functions are useful. Similarly for pg_operator.oprcode.
>
> Things like oprrest and opr
On 6 April 2018 at 13:29, Peter Eisentraut
wrote:
> I looked at this a bit now. I think it still needs some work.
Hi Peter, thanks for the feedback.
> Some of the queries for older versions contain syntax errors that causes
> them not to work.
>
> For example, in 80100:
>
> "'internal'::regtype
On 29 March 2018 at 20:46, Michael Paquier wrote:
> On Tue, Mar 27, 2018 at 03:47:07PM +1300, Edmund Horner wrote:
>> But the stats array includes auxiliary processes, which means it has
>> NumBackendStatSlots items. The pointers for the aux process strings
>> are out of r
On 30 March 2018 at 19:26, Fabien COELHO wrote:
> Thanks for the check. You might consider turning the patch as ready in the
> cf app.
Ok, I have done so, since the patch is small and simple.
>> Fixing the abs/hash bracketing seems clear. The wasn't sure about
>> rewriting "mod(i, bj)" as "mod(
I did a quick review of this.
The patch is just a doc typo fix and it applies cleanly to master (as of this
email). I was able to build the docs, and they look ok.
Fixing the abs/hash bracketing seems clear. The wasn't sure about rewriting
"mod(i, bj)" as "mod(i, j)", because there could be s
I sent the original in haste, and now I need to make some corrections... sigh.
> Subject: Fix for pg_stat_activity putting client hostaddr into appname field
Actually, it's the hostname appears in the appname field.
> I noticed when querying pg_stat_activity (in 10.1):
10.1 was where I first no
I noticed when querying pg_stat_activity (in 10.1):
$ SELECT pid, application_name, client_hostname, backend_type FROM
pg_stat_activity;
pid | application_name |client_hostname| backend_type
---+--+---+
On 8 March 2018 at 17:23, Edmund Horner wrote:
> New patch that fixes a little bug with appending NULL addons to schema
> queries.
Hi all, I haven't heard anything for a while and so assume you're
beavering away on real features. :)
I've been dogfooding this patch at work
Some updates on patch status:
- "version-dependent-tab-completion-1.patch" by Tom Lane was committed in
722408bcd.
- "psql-tab-completion-savepoint-v1.patch" by Edmund Horner is probably not
needed.
- "psql-select-tab-completion-v6.patch" (the latest) is still under
development/review.
New patch that fixes a little bug with appending NULL addons to schema queries.
psql-select-tab-completion-v6.patch
Description: Binary data
I've reworked the SELECT completion patch to use the VersionedQuery
infrastructure.
I've also made it a schema query (for the functions), with an addon
for the attributes. This provides schema-aware completion.
Previously, addons to schema queries were appended verbatim; I've
changed this to use
On 5 March 2018 at 21:46, Vik Fearing wrote:
> Tab completion on functions in SELECT (a subset of this thread's patch)
> is quite important to me personally. I will work on this in the coming
> days.
It's something I've missed numerous times in the last few months at
work. I guess I should real
On 5 March 2018 at 08:06, Tom Lane wrote:
> I looked into this patch and was disappointed to discover that it had
> only a very ad-hoc solution to the problem of version-dependent tab
> completion queries. We need something better --- in particular, the
> recent prokind changes mean that there ne
Hi folks,
While working on tab completion for SELECT I found a few existing
problems with how psql's tab completion queries interact with
transactions.
- If a tab completion query fails, it will abort the user's
transaction. For example, typing, "ALTER PUBLICATION " when
connected to an older
On 26 January 2018 at 13:44, Vik Fearing wrote:
> On 01/26/2018 01:28 AM, Edmund Horner wrote:
>> The patch mentioned attempts to put savepoints around the tab
>> completion query where appropriate.
>
> I am -1 on this idea.
May I ask why? It doesn't stop psql working
On 19 January 2018 at 05:37, Vik Fearing wrote:
> On 01/18/2018 01:07 AM, Tom Lane wrote:
>> Edmund Horner writes:
>>> On 15 January 2018 at 15:45, Andres Freund wrote:
>>>> All worries like this are supposed to check the server version.
>>
>>> In
On 23 January 2018 at 21:47, Vik Fearing wrote:
> Don't forget to include the list :-)
> I'm quoting the entirety of the message---which I would normally trim---for
> the archives.
Thanks for spotting that. Sorry list!
> If this were my patch, I'd have one query for 8.0, and then queries for al
On 15 January 2018 at 15:45, Andres Freund wrote:
> On January 14, 2018 5:44:01 PM PST, Edmund Horner wrote:
>>In psql if you have readline support and press TAB, psql will often
>>run a DB query to get a list of possible completions to type on your
>>current command l
On 15 January 2018 at 14:20, Andres Freund wrote:
> On January 14, 2018 5:12:37 PM PST, Edmund Horner wrote:
>>And here's a patch to add savepoint protection for tab completion.
>
> It'd be good to explain what that means, so people don't have to read the
> pa
And here's a patch to add savepoint protection for tab completion.
It could definitely use some scrutiny to make sure it's not messing up
the user's transaction.
I added some error checking for the savepoint creation and the
rollback, and then wrapped it in #ifdef NOT_USED (just as the query
erro
Hi, here's a new patch.
This one makes some changes to the criteria for which functions to
include; namely filtering out trigger functions and those that take or
return values of type "internal"; and including aggregate and window
functions. Some of the other checks could be removed as they were
On 11 January 2018 at 03:28, Vik Fearing wrote:
> On 01/10/2018 06:38 AM, Edmund Horner wrote:
>> Regarding support for older versions, psql fails silently if a tab
>> completion query fails.
>
> No it doesn't, see below.
>
>> We could just let it do this,
Hi Vik, thanks so much for the comments and the offer to review!
I kept a low profile after my first message as there was already a
commitfest in progress, but now I'm working on a V2 patch.
I will include aggregate and window functions as you suggest. And
I'll exclude trigger functions.
I'd li
74 matches
Mail list logo
