> On Fri, Jun 21, 2024 at 01:28:11PM +0900, Michael Paquier wrote:
> On Fri, Jun 21, 2024 at 01:09:10PM +0900, Kyotaro Horiguchi wrote:
> > At Thu, 13 Jun 2024 16:59:50 +0900, Michael Paquier
> > wrote in
> >> * The kind IDs may change across restarts, meaning that any stats data
> >> associated
> On Thu, Jul 11, 2024 at 04:42:22PM GMT, Michael Paquier wrote:
>
> So we are down to the remaining parts of the patch, and this is going
> to need a consensus about a few things because this impacts the
> developer experience when implementing one's own custom stats:
> - Are folks OK with the poi
> On Tue, Jul 18, 2023, 3:32 PM Daniel Gustafsson wrote
>> Here is the patch with the proposed variation.
>
> This version still leaves non-text EXPLAIN formats with timing which
doesn't
> add up. Below are JSON and XML examples:
Good point. For the structured formats it should be represented vi
Hi,
In the commit [1] one side change was to fix mixed up usage of
BlockNumber and Buffer variables. This was a one-off manual effort, and
indeed it hardly seems possible to get compilation warnings for such
code, as long as the underlying types could be converted in a standard
conforming way. As
> On Thu, Aug 03, 2023 at 12:23:52PM -0500, Tristan Partin wrote:
>
> This is the first I am learning about clang plugins. Interesting concept.
> Did you give any thought to using libclang instead of a compiler plugin? I
> am kind of doing similar work, but I went with libclang instead of a plugin.
> On Wed, Aug 09, 2023 at 03:23:32PM +0200, Peter Eisentraut wrote:
> On 03.08.23 18:56, Dmitry Dolgov wrote:
> > I would like to get your opinion, folks. Does it sound interesting
> > enough for the community, is it worth it to pursue the idea?
>
> I think it's inte
> On Thu, Aug 03, 2023 at 08:15:13AM +0200, Pavel Stehule wrote:
> Hi
>
> fresh rebase
Thanks for continuing efforts. The new patch structure looks better to
me (although the boundary between patches 0001 and 0002 is somewhat
fuzzy, e.g. the function NameListToString is used already in the first
o
> On Sat, Aug 12, 2023 at 09:28:19AM +0800, Julien Rouhaud wrote:
> On Fri, Aug 11, 2023 at 05:55:26PM +0200, Dmitry Dolgov wrote:
> >
> > Another confusing example was this one at the end of set_session_variable:
> >
> > + /*
> > +*
> On Wed, Jul 19, 2023 at 05:18:29PM +0200, Dmitry Dolgov wrote:
> > On Tue, Jul 18, 2023, 3:32 PM Daniel Gustafsson wrote
> >> Here is the patch with the proposed variation.
> >
> > This version still leaves non-text EXPLAIN formats with timing which
> doesn'
Hi,
I would like to propose a small patch to address an annoying issue with
the way how PostgreSQL does fallback in case if "huge_pages = try" is
set. Here is how the problem looks like:
* PostgreSQL is starting on a machine with some huge pages available
* It tries to identify that fact and doe
> On Mon, Apr 15, 2024 at 06:09:29PM +0900, Sutou Kouhei wrote:
>
> Thanks. I'm not familiar with this code base but I've
> reviewed these patches because I'm interested in this
> feature too.
Thanks for the review! The commentaries for the first patch make sense
to me, will apply.
> 0003:
>
> >
> On Thu, Apr 25, 2024 at 06:38:58PM +0300, Maxim Orlov wrote:
>
> And then upon build I've got overwhelmed by thousands of undefined
> reference errors.
>
> fe-auth-scram.c:(.text+0x17a): undefined reference to
> `__ubsan_handle_builtin_unreachable'
> /usr/bin/ld: fe-auth-scram.c:(.text+0x189): un
> On Tue, Apr 30, 2024 at 04:29:11PM +0530, Ashutosh Bapat wrote:
> On Sun, Apr 28, 2024 at 12:29 PM Alexander Lakhin
> wrote:
>
> > 27.04.2024 18:00, Alexander Lakhin wrote:
> > >
> > > Please look also at another script, which produces the same error:
> >
> > I've discovered yet another problema
> On Mon, May 06, 2024 at 06:52:41PM +0530, Ashutosh Bapat wrote:
> On Sun, May 5, 2024 at 1:43 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > I had a quick look, it covers the issues mentioned above in the thread.
> > Few nitpicks/questions:
> >
> > * I t
> On Sat, May 04, 2024 at 01:55:22AM +1200, David Rowley wrote:
> (40af10b57 did this for tuplesort.c, this is the same, but for tuplestore.c)
An interesting idea, thanks. I was able to reproduce the results of your
benchmark and get similar conclusions from the results.
> Using generation has th
> On Tue, Apr 23, 2024 at 10:18:15AM +0200, Dmitry Dolgov wrote:
> > On Mon, Apr 15, 2024 at 06:09:29PM +0900, Sutou Kouhei wrote:
> >
> > Thanks. I'm not familiar with this code base but I've
> > reviewed these patches because I'm interested in this
>
fy pass on all generated IR.
We fixed a recent problem that crashed LLVM 18, but Dmitry pointed out
that we'd have known about that all along if we'd automatically run the
verify pass on the IR we generate.
Turn that on in assertion builds. That reveals one other complaint
about a
> On Thu, May 16, 2024 at 02:30:03PM -0400, Robert Haas wrote:
>
> I wonder what ideas people have for improving this situation. I doubt
> that there's any easy answer that just makes the problem go away --
> keeping large groups of people organized is a tremendously difficult
> task under pretty m
> On Wed, May 22, 2024 at 02:37:49PM +0200, Peter Eisentraut wrote:
> On 18.05.24 13:29, Alvaro Herrera wrote:
> > I want to note that when we discussed this patch series at the dev
> > meeting in FOSDEM, a sort-of conclusion was reached that we didn't want
> > schema variables at all because of th
> On Wed, May 22, 2024 at 08:44:28PM +0200, Pavel Stehule wrote:
> st 22. 5. 2024 v 19:25 odesílatel Tom Lane napsal:
>
> > Peter Eisentraut writes:
> > > On 18.05.24 13:29, Alvaro Herrera wrote:
> > >> I want to note that when we discussed this patch series at the dev
> > >> meeting in FOSDEM, a
> On Tue, May 28, 2024 at 05:18:02PM GMT, Pavel Stehule wrote:
>
> I propose another variants. First we can introduce pseudo function VAR( ).
> The argument should be session variables. The name of this function can be
> pgvar, globvar, ... We can talk about good name, it should not be too long,
>
> On Mon, May 22, 2023 at 03:38:44PM +1200, Thomas Munro wrote:
> Further changes are already needed for their "main" branch (LLVM
> 17-to-be), so this won't quite be enough to shut seawasp up. At a
> glance, we will need to change from the "old pass manager" API that
> has recently been vaporised
> On Mon, Jun 05, 2023 at 06:43:54PM +0300, Heikki Linnakangas wrote:
> On 05/06/2023 11:28, Tristan Partin wrote:
> > > # Exposed PIDs
> > >
> > > We expose backend process PIDs to users in a few places.
> > > pg_stat_activity.pid and pg_terminate_backend(), for example. They need
> > > to be repl
> On Mon, Jul 03, 2023 at 09:46:11PM -0700, Nathan Bossart wrote:
Thanks for reviewing.
> On Sun, Mar 19, 2023 at 01:27:34PM +0100, Dmitry Dolgov wrote:
> > +If this parameter is on, two queries with an array will get the
> > same
> > +query identifie
In many jit related bug reports, one of the first questions is often
"which llvm version is used". How about adding it into the
PG_VERSION_STR, similar to the gcc version?
>From 9a4404c0df92f96ab98fca3ff0d7952287c30ece Mon Sep 17 00:00:00 2001
From: Dmitrii Dolgov <9erthali...@gmail.com>
Date: Tue,
> On Sun, Jul 28, 2024 at 10:20:45PM GMT, Michael Paquier wrote:
> I would like to apply this new infrastructure stuff and move on to the
> problems related to the scability of pg_stat_statements. So, are
> there any objections with all that?
So far I've got nothing against :)
> On Wed, Jun 26, 2024 at 03:16:07PM GMT, Peter Geoghegan wrote:
>
> Loose index scan is a far more specialized technique than skip scan.
> It only applies within special scans that feed into a DISTINCT group
> aggregate. Whereas my skip scan patch isn't like that at all -- it's
> much more general
> On Fri, Aug 02, 2024 at 08:47:02AM GMT, Stefan Fercot wrote:
>
> Not sure why CFbot CI fails on macOS/Windows while it works with the Github
> CI on my fork (
> https://cirrus-ci.com/github/pgstef/postgres/partial-walseg-recovery).
I guess it's because the test has to wait a bit after the node h
> On Sun, Aug 11, 2024 at 07:54:05PM +0300, Sergei Kornilov wrote:
>
> This feature will improve my monitoring. Even in patch 0001. I think there
> are many other people in the thread who think this is useful. So maybe we
> should move it forward? Any complaints about the overall design? I see in
> On Sun, Aug 11, 2024 at 09:34:55PM GMT, Dmitry Dolgov wrote:
> > On Sun, Aug 11, 2024 at 07:54:05PM +0300, Sergei Kornilov wrote:
> >
> > This feature will improve my monitoring. Even in patch 0001. I think there
> > are many other people in the thread who think
> On Fri, Jun 05, 2020 at 12:26:15PM +1200, David Rowley wrote:
> On Mon, 25 May 2020 at 19:14, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> >
> > > On Mon, May 25, 2020 at 06:34:30AM +1200, David Rowley wrote:
> > > The difference will be that you'd be
> On Sun, Jun 07, 2020 at 06:51:22PM +1200, David Rowley wrote:
>
> > * one in create_distinct_paths as per current implementation
> >
> > with what seems to be similar content.
>
> I think we need to have UniqueKeys in RelOptInfo so we can describe
> what a relation is unique by. There's no point
> On Sat, May 16, 2020 at 04:56:09PM +0200, Tomas Vondra wrote:
>
> So I don't think there will be a single "interesting" grouping pathkeys
> (i.e. root->group_pathkeys), but a collection of pathkeys. And we'll
> need to build grouping paths for all of those, and leave the planner to
> eventually p
> On Thu, Jun 11, 2020 at 04:14:07PM +0800, Andy Fan wrote:
>
> I just get the rough idea of patch, looks we have to narrow down the
> user cases where we can use this method. Consider the below example:
Hi
Not exactly narrow down, but rather get rid of wrong usage of skipping
for index scan. Sin
> On Wed, Jul 08, 2020 at 03:44:26PM -0700, Peter Geoghegan wrote:
>
> On Tue, Jun 9, 2020 at 3:20 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > * Btree-implementation contains btree specific code to implement amskip,
> > introduced in the previous patch.
>
> On Fri, Jul 10, 2020 at 05:03:37PM +, Floris Van Nee wrote:
>
> Also took another look at the patch now, and found a case of incorrect
> data. It looks related to the new way of creating the paths, as I
> can't recall seeing this in earlier versions.
>
> create table t1 as select a,b,b%5 as c
> On Sun, Jul 12, 2020 at 12:48:47PM +, Floris Van Nee wrote:
> >
> > Good point, thanks for looking at this. With the latest planner version
> > there
> > are indeed more possibilities to use skipping. It never occured to me that
> > some of those paths will still rely on index scan returning
ppend_rel(PlannerInfo *root, RelOptInfo *rel,
List *live_childrels);
+/*
+ * uniquekey.c
+ * Utilities for matching and building unique keys
+ */
+extern List *build_uniquekeys(PlannerInfo *root, List *sortclauses);
+extern bool uniquekeys_contained_in(List *keys1, List *keys2);
+exter
> On Thu, Apr 09, 2020 at 09:55:25AM +1200, Thomas Munro wrote:
> Thanks. Here's a rebase.
Thanks for working on this patch, it seems like a great feature. I'm
probably a bit late to the party, but still want to make couple of
commentaries.
The patch indeed looks good, I couldn't find any signif
> On Tue, Apr 21, 2020 at 05:26:52PM +1200, Thomas Munro wrote:
>
> One report I heard recently said that if you get rid of I/O stalls,
> pread() becomes cheap enough that the much higher frequency lseek()
> calls I've complained about elsewhere[1] become the main thing
> recovery is doing, at lea
> On Sat, Apr 25, 2020 at 09:19:35PM +0200, Dmitry Dolgov wrote:
> > On Tue, Apr 21, 2020 at 05:26:52PM +1200, Thomas Munro wrote:
> >
> > One report I heard recently said that if you get rid of I/O stalls,
> > pread() becomes cheap enough that the much higher frequ
Sorry for late reply.
> On Tue, Apr 14, 2020 at 09:19:22PM +1200, David Rowley wrote:
>
> I've not yet looked at the latest patch, but I did put some thoughts
> into an email on the other thread that's been discussing UniqueKeys
> [1].
>
> I'm keen to hear thoughts on the plan I mentioned over the
> On Sat, Apr 11, 2020 at 03:17:25PM +0530, Dilip Kumar wrote:
>
> Some more comments...
Thanks for reviewing. Since this patch took much longer than I expected,
it's useful to have someone to look at it with a "fresh eyes".
> + so->skipScanKey->nextkey = ScanDirectionIsForward(dir);
> + _bt_upda
> On Mon, May 11, 2020 at 04:04:00PM +0530, Dilip Kumar wrote:
>
> > > +static inline bool
> > > +_bt_scankey_within_page(IndexScanDesc scan, BTScanInsert key,
> > > + Buffer buf, ScanDirection dir)
> > > +{
> > > + OffsetNumber low, high;
> > > + Page page = BufferGetPage(buf);
> > > + BTPageOpaqu
> On Wed, May 13, 2020 at 02:37:21PM +0530, Dilip Kumar wrote:
>
> + if (_bt_scankey_within_page(scan, so->skipScanKey, so->currPos.buf, dir))
> + {
>
> Here we expect whether the "next" unique key can be found on this page
> or not, but we are using the function which suggested whether the
> "curr
> On Fri, May 15, 2020 at 01:52:20AM +0200, Tomas Vondra wrote:
>
> I wonder if anyone has plans to try again with this optimization in v14
> cycle? The patches no longer apply thanks to the incremental sort patch,
> but I suppose fixing that should not be extremely hard.
>
> The 2020-07 CF is stil
> On Tue, Apr 14, 2020 at 09:09:31PM +1200, David Rowley wrote:
>
> The infrastructure (knowing the unique properties of a RelOptInfo), as
> provided by the patch Andy has been working on, which is based on my
> rough prototype version, I believe should be used for the skip scans
> patch as well.
> On Fri, May 22, 2020 at 08:40:17AM +1200, David Rowley wrote:
>
> The way I picture the two working together is that the core UniqueKey
> patch adds UniqueKeys to RelOptInfos to allow us to have knowledge
> about what they're unique on based on the base relation's unique
> indexes.
Yep, I'm onbo
> On Mon, May 25, 2020 at 06:34:30AM +1200, David Rowley wrote:
>
> > For a simple distinct query those UniqueKeys would be set based on
> > distinct clause. If I understand correctly, the very same is implemented
> > right now in create_distinct_paths, just after building all index paths,
> > so w
> On Tue, Jun 02, 2020 at 08:36:31PM +0800, Andy Fan wrote:
>
> > Other than that to summarize current open points for future readers
> > (this thread somehow became quite big):
> >
> > * Making UniqueKeys usage more generic to allow using skip scan for more
> > use cases (hopefully it was covere
> On Fri, Jan 18, 2019 at 11:22 AM Amit Khandekar
> wrote:
>
> --- a/src/test/regress/expected/copy2.out
> +++ b/src/test/regress/expected/copy2.out
> @@ -1,3 +1,4 @@
> +\set HIDE_TABLEAM on
>
> I thought we wanted to avoid having to add this setting in individual
> regression tests. Can't we do
> On Mon, Jan 21, 2019 at 3:01 AM Andres Freund wrote:
>
> The patchset is now pretty granularly split into individual pieces.
Wow, thanks!
> On Mon, Jan 21, 2019 at 9:33 AM Amit Khandekar wrote:
>
> Regression tests that use \d+ to show the table details might
> not be interested specifically
> On 2019-01-17 09:29:04 -0800, Andres Freund wrote:
> On 2019-01-17 10:23:39 -0500, Tom Lane wrote:
> > I don't buy the argument that this would move the goalposts in terms
> > of how much work it is to add a new argument. You'd still end up
> > touching every call site.
>
> Why? A lot of argumen
Here is another version, where I accumulated all the suggestions:
* Use NULL as a default value where it was an empty string before (this
required few minor changes for some part of the code outside ArchiveEntry)
* Rename defn, descr to createStmt, description
* Use a macro to avoid pgindent e
> On Thu, Dec 20, 2018 at 2:46 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> I've performed some testing, and on my environment with a dataset of 10^7
> records:
>
> * everything below 7.5 * 10^5 unique records out of 10^7 was faster with skip
> scan.
>
> On Sat, Jan 26, 2019 at 6:45 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> Rebased version after rd_amroutine was renamed.
And one more to fix the documentation. Also I've noticed few TODOs in the patch
about the missing docs, and replaced them with a required explan
> On Sun, Jan 20, 2019 at 6:17 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Fri, Jan 18, 2019 at 11:22 AM Amit Khandekar
> > wrote:
> >
> > I believe you are going to add a new regression testcase for the change ?
>
> Yep.
So, here are the
> On Sun, Jan 27, 2019 at 6:17 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Sat, Jan 26, 2019 at 6:45 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> >
> > Rebased version after rd_amroutine was renamed.
>
> And one more to fix the documen
> On Thu, Jan 31, 2019 at 4:39 PM Alvaro Herrera
> wrote:
>
> That having been said ... while the current 0001 patch does apply
> semi-cleanly (`git apply -3` does it), it does not compile, probably
> because of header refactoring. Please rebase and make sure that each
> individual patch compile
> On Fri, Feb 1, 2019 at 12:54 PM Alvaro Herrera
> wrote:
>
> On 2019-Feb-01, Alvaro Herrera wrote:
>
> > On 2019-Feb-01, Alvaro Herrera wrote:
> >
> > ... and you're going to need "git format-patch -v19", because contrib
> > doesn't build with 18.
>
> And that suggests that maybe we should keep
> On Fri, Feb 1, 2019 at 12:33 PM Alvaro Herrera
> wrote:
>
> pgindent didn't like your layout with two-space indents for the struct
> members :-( I thought it was nice, but oh well. This means we can do
> away with the newline at each callsite, and I didn't like the trailing
> comma (and I hav
> On Fri, Feb 1, 2019 at 4:55 PM Alvaro Herrera
> wrote:
>
> On 2019-Feb-01, Dmitry Dolgov wrote:
>
> > The moment was longer than I expected, but here is the rebased version,
> > where
> > all the individual patches can be applied and compiled cleanly
> On Tue, Feb 5, 2019 at 12:54 AM Alvaro Herrera
> wrote:
>
> Actually, index-based replica identities failed in pg_dump: we first
> create the index ONLY on the partitioned table (marking it as invalid),
> so when we immediately do the ALTER TABLE/REPLICA IDENTITY, it rejects
> the invalid index
uch less endangered than sessions with lots
> of very small queries. But I think that means it needs to be
> controllable from both the server and client, and default to off
> (although it doesn't seem crazy to allow it in the aforementioned
> cases).
Totally agree with this point.
> On Wed, Feb 13, 2019 at 3:46 PM Konstantin Knizhnik
> wrote:
>
> Moreover, please notice that your implementation is still passing functions
> tx/rx functions to stream constructor and so zpq_read is still able to read
> data itself. So I do not understand which problem you have solved by
> repl
> On Wed, Feb 13, 2019 at 3:52 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Wed, Feb 13, 2019 at 3:46 PM Konstantin Knizhnik
> > wrote:
> >
> > Moreover, please notice that your implementation is still passing functions
> > tx/rx function
For the records, I'm really afraid of interfering with the conversation at this
point, but I believe it's necessary for the sake of a good feature :)
> On Wed, Feb 13, 2019 at 4:03 PM Konstantin Knizhnik
> wrote:
>
> 1. When decompressor has not enough data to produce any extra output, it
> does
> On Fri, Feb 15, 2019 at 10:02 PM Alvaro Herrera
> wrote:
>
> On 2019-Feb-07, Dmitry Dolgov wrote:
>
> > Could there be a race condition somewhere? The idea and the code looks
> > reasonable, but when I'm testing ALTER TABLE ... REPLICA IDENTITY with this
&g
> On Fri, Feb 1, 2019 at 8:24 PM Jesper Pedersen
> wrote:
>
> Dmitry and I will look at this and take it into account for the next
> version.
In the meantime, just to not forget, I'm going to post another version with a
fix for cursor fetch backwards, which was crashing before. And talking about
> On Mon, Feb 25, 2019 at 8:45 AM hubert depesz lubaczewski
> wrote:
>
> I did upgrade of my test pg. Part of this is pg_dump -Fd of each
> database, then upgrade binaries, then initdb, and pg_restore.
>
> But - I can't restore any database that has any data - I get segfaults.
Thank for reportin
> On Tue, Feb 26, 2019 at 6:38 AM Michael Paquier wrote:
>
> Works for me. With a quick read of the code, it seems to me that it
> is possible to keep compatibility while keeping the simplifications
> around ArchiveEntry()'s refactoring.
Yes, it should be rather simple, we can e.g. return to the
> On Tue, Feb 26, 2019 at 9:13 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Tue, Feb 26, 2019 at 6:38 AM Michael Paquier wrote:
> >
> > Works for me. With a quick read of the code, it seems to me that it
> > is possible to keep compatibili
> On Tue, Feb 26, 2019 at 11:53 PM Alvaro Herrera
> wrote:
>
> On 2019-Feb-26, Dmitry Dolgov wrote:
>
> > Yes, it should be rather simple, we can e.g. return to the old less
> > consistent
> > NULL handling approach something (like in the attached patch), or r
ll
> callsites anyway.
I guess we can keep the part about removing null checks before using strlen,
since it's going to be useless.
> On Wed, Feb 27, 2019 at 10:36 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Tue, Feb 26, 2019 at 11:53 PM Alvaro Herrera
>
> On Fri, Nov 30, 2018 at 10:31 PM Юрий Соколов wrote:
>
>> Due to lack of response and taking into account this commentary, I'm marking
>> this patch as "Returned with feedback", but hopefully I can pick it up later
>> to
>> improve.
>
> Good luck.
Unexpected for me, but promising reaction - re
> On Mon, Nov 19, 2018 at 8:30 AM Julien Demoor wrote:
>
> Thank you for the review. I've addressed all your points in the attached
> patch. The patch was made against release 11.1.
I've noticed, that cfbot complains about this patch [1], since:
Duplicate OIDs detected:
3423
found 1 duplicate OI
> On Mon, Nov 19, 2018 at 2:30 PM Nikolay Shaplov wrote:
>
> В письме от 2 октября 2018 13:46:13 пользователь Michael Paquier написал:
> > On Fri, Sep 14, 2018 at 09:30:25PM +0300, Nikolay Shaplov wrote:
> > > BTW this commit shows why do this patch is important: 857f9c36 adds new
> > > option for
> On Mon, Nov 19, 2018 at 4:58 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Tue, Jul 24, 2018 at 5:52 PM Dave Cramer wrote:
> >
> > Back in 2016 a patch was proposed that seems to have died on the vine. See
> > https:
> On Wed, Nov 21, 2018 at 8:25 AM Pavel Stehule wrote:
>
> just rebase
Thanks for working on this patch.
I'm a bit confused, but cfbot again says that there are some conflicts.
Probably they are the minor one, from src/bin/psql/help.c
For now I'm moving it to the next CF.
On Sat, Dec 1, 2018 at 12:17 AM Dave Cramer wrote:
>
> Why is this being closed? I did not see the first email looking for
> clarification.
Well, mostly due total absence of response and broken mind reading crystal ball.
> I can certainly rebase it.
Yes, please do. I'll change the CF item stat
>On Sat, Dec 1, 2018 at 12:49 AM Dave Cramer wrote:
>
> Thanks, I have done a preliminary check and it seems pretty straightforward.
>
> I will clean it up for Monday
Great, thank you!
> On Thu, Nov 22, 2018 at 11:11 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Wed, Jul 18, 2018 at 10:27 AM Heikki Linnakangas wrote:
> >
> > On 16/07/18 15:56, Peter Eisentraut wrote:
> > > On 11.07.18 19:07, Heikki Linnakangas wrote:
> >
> On Wed, Nov 21, 2018 at 1:38 PM Michael Banck
> wrote:
>
> Hi,
>
> On Tue, Oct 30, 2018 at 06:22:52PM +0100, Fabien COELHO wrote:
> > >I am not convinced we need to differentiate further between online and
> > >offline operation, can you explain in more detail which other
> > >differences are o
> On Sun, Nov 25, 2018 at 12:14 AM Peter Geoghegan wrote:
>
> Attached is v8 of the patch series, which has some relatively minor changes:
Thank you for working on this patch,
Just for the information, cfbot says there are problems on windows:
src/backend/catalog/pg_depend.c(33): error C2065: '
> On Mon, Nov 26, 2018 at 9:31 AM John Naylor wrote:
>
> v7 is a rebase over recent catalog changes.
Thanks for working on this,
I see that the author keeps patch updated, but I'm a bit worried because of
lack of full review since probably May. I'm moving it to the next CF, let's see
if there wo
> On Mon, Nov 26, 2018 at 5:11 PM Nikita Glukhov
> wrote:
>
> On 26.11.2018 15:57, Dmitry Dolgov wrote:
>
> >> On Tue, Jul 3, 2018 at 2:57 PM Pavel Stehule
> >> wrote:
> >>
> >> 2018-07-03 14:30 GMT+02:00 Nikita Glukhov :
> >>>
> On Mon, Nov 26, 2018 at 9:19 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Tue, Aug 7, 2018 at 11:19 PM Bruce Momjian wrote:
> >
> > On Mon, Jul 16, 2018 at 11:37:28AM -0400, Tom Lane wrote:
> > > Heikki Linnakangas writes:
> > > >
> On Mon, Nov 26, 2018 at 11:47 PM Thomas Munro
> wrote:
>
> On Fri, Nov 23, 2018 at 5:45 PM Thomas Munro
> wrote:
> > I do have a new plan though...
>
> Ugh. The plan in my previous email doesn't work, I was confused about
> the timing of the buffer header update. Back to the drawing board.
> On Tue, Nov 27, 2018 at 11:40 AM Kyotaro HORIGUCHI
> wrote:
>
> The attached is the rebased version that has multidimentional
> ageclass.
Thank you,
Just for the information, cfbot complains about this patch because:
pgstatfuncs.c: In function ‘pgstat_get_syscache_stats’:
pgstatfuncs.c:1973:
> On Wed, Nov 28, 2018 at 9:26 PM Alexander Korotkov
> wrote:
>
> On Sat, Nov 24, 2018 at 11:03 PM Tomas Vondra
> wrote:
> > I've done another round of reviews on v20, assuming the patch is almost
> > ready to commit, but unfortunately I ran into a bunch of issues that
> > need to be resolved. N
> On Sat, Dec 1, 2018 at 9:08 PM Daniel Verite wrote:
>
> Dmitry Dolgov wrote:
>
> > As a side note, I'm a bit confused, who is the original author of
> > the proposed patch? If it's Marina, why she isn't involved in the
> > discussion o
> On Fri, Nov 16, 2018 at 2:05 AM Haribabu Kommi
> wrote:
>
> I tried running the pgbench performance tests with minimal clients in my
> laptop and I didn't
> find any performance issues, may be issue is visible only with higher
> clients. Even with
> perf tool, I am not able to get a clear pro
> On Thu, Nov 29, 2018 at 6:48 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Tue, Oct 2, 2018 at 4:53 AM Michael Paquier wrote:
> >
> > On Mon, Aug 06, 2018 at 06:00:54PM +0900, Yoshimi Ichiyanagi wrote:
> > > The libpmem's pmem_map_
> On Tue, Dec 11, 2018 at 3:13 AM Andres Freund wrote:
>
> Hi,
>
> On 2018-11-26 17:55:57 -0800, Andres Freund wrote:
> > FWIW, now that oids are removed, and the tuple table slot abstraction
> > got in, I'm working on rebasing the pluggable storage patchset ontop of
> > that.
>
> I've pushed a ve
> On Tue, Dec 11, 2018 at 3:13 AM Andres Freund wrote:
>
> Further tasks I'm not yet planning to tackle, that I'd welcome help on:
> - pg_dump support
> - pg_upgrade testing
> - I think we should consider removing HeapTuple->t_tableOid, it should
> imo live entirely in the slot
I'm a bit confus
> On Sat, Dec 15, 2018 at 8:37 PM Andres Freund wrote:
>
> We need to dump the table access method at dump time, otherwise we loose
> that information.
Oh, right. So, something like in the attached patch?
> > As a side note, in a table description I haven't found any mention of which
> > access
> On Thu, Dec 20, 2018 at 6:53 AM David Rowley
> wrote:
>
> Thomas mentions in [1], to get the GCC to use the POPCNT instruction,
> we must pass -mpopcnt in the build flags. After doing a bit of
> research, I found [2] which mentions that some compilers have some
> pattern matching code to allow
> On Wed, Nov 21, 2018 at 9:56 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Wed, Nov 21, 2018 at 4:38 PM Alexander Kuzmenkov
> > wrote:
> >
> > On 11/18/18 02:27, Dmitry Dolgov wrote:
> > >
> > > [0001-Index-skip-scan-v4.patch]
&
> On Thu, Nov 22, 2018 at 6:04 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> Absolutely agree. Looking at the history of the patch I see that it went
> through some extensive review and even was marked as Ready for Committer
> before
> the commentary from Peter, but
> On Fri, Jan 4, 2019 at 1:38 PM David Rowley
> wrote:
>
> On Thu, 20 Dec 2018 at 23:56, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > I've checked for Clang 6, it turns out that indeed it generates popcnt
> > without
> > any macro, but only in
401 - 500 of 725 matches
Mail list logo
