On Tue, Apr 14, 2020 at 9:14 PM Erik Rijkers wrote:
>
> On 2020-04-14 12:10, Dilip Kumar wrote:
>
> > v14-0001-Immediately-WAL-log-assignments.patch +
> > v14-0002-Issue-individual-invalidations-with.patch +
> >
On Tue, 14 Apr 2020 at 18:35, Kyotaro Horiguchi wrote:
>
> At Tue, 14 Apr 2020 13:06:14 +0900, Masahiko Sawada
> wrote in
> > On Tue, 14 Apr 2020 at 10:34, Tom Lane wrote:
> > >
> > > Kyotaro Horiguchi writes:
> > > > At Sat, 11 Apr 2020 18:30:30 -0400, Tom Lane wrote
> > > > in
> > > >>
On 2020/04/14 2:40, Robert Haas wrote:
On Fri, Mar 27, 2020 at 4:32 PM Andres Freund wrote:
I don't like having a file format that's intended to be used by external
tools too that's undocumented except for code that assembles it in a
piecemeal fashion. Do you mean in a follow-on patch this
On Wed, 15 Apr 2020 at 03:41, Tom Lane wrote:
>
> David Rowley writes:
> > For testing, can't we just have an Assert() in
> > advance_transition_function that verifies isnull matches the
> > nullability of the return value for INTERNAL returning transfns? i.e,
> > the attached
>
> FTR, I do not
On Wed, Apr 15, 2020 at 9:03 AM Justin Pryzby wrote:
>
> On Wed, Apr 15, 2020 at 08:54:17AM +0530, Amit Kapila wrote:
> > On Tue, Apr 14, 2020 at 8:55 AM Amit Kapila wrote:
> > >
> > > On Tue, Apr 14, 2020 at 7:52 AM Michael Paquier
> > > wrote:
> > > >
> > >
> > > > -VACUUM (PARALLEL 1) tmp;
On Wed, Apr 15, 2020 at 08:54:17AM +0530, Amit Kapila wrote:
> On Tue, Apr 14, 2020 at 8:55 AM Amit Kapila wrote:
> >
> > On Tue, Apr 14, 2020 at 7:52 AM Michael Paquier wrote:
> > >
> >
> > > -VACUUM (PARALLEL 1) tmp; -- disables parallel vacuum option
> > > +VACUUM (PARALLEL 1) tmp; --
On Tue, Apr 14, 2020 at 8:55 AM Amit Kapila wrote:
>
> On Tue, Apr 14, 2020 at 7:52 AM Michael Paquier wrote:
> >
>
> > -VACUUM (PARALLEL 1) tmp; -- disables parallel vacuum option
> > +VACUUM (PARALLEL 1) tmp; -- parallel vacuum disabled for temp tables
> > WARNING: disabling parallel option
On Tue, Apr 14, 2020 at 04:32:40PM -0400, Tom Lane wrote:
> I wrote:
> > It doesn't seem to me to be that hard to implement the desired
> > semantics for synchronous_standby_names with inconsistent info.
> > In FIRST mode you basically just need to take the N smallest
> > priorities you see in the
On Wed, 15 Apr 2020 at 12:19, Andy Fan wrote:
>
>> 2. I think 0002 is overly restrictive in its demands that
>> parse->hasAggs must be false. We should be able to just use a Group
>> Aggregate with unsorted input when the input_rel is unique on the
>> GROUP BY clause. This will save on hashing
At Tue, 14 Apr 2020 16:32:40 -0400, Tom Lane wrote in
> I wrote:
> > It doesn't seem to me to be that hard to implement the desired
> > semantics for synchronous_standby_names with inconsistent info.
> > In FIRST mode you basically just need to take the N smallest
> > priorities you see in the
On Mon, Apr 13, 2020 at 2:58 PM Thomas Munro wrote:
> On Fri, Apr 3, 2020 at 2:22 PM Peter Geoghegan wrote:
> > I think that it's worth considering whether or not there are a
> > significant number of "snapshot too old" users that rarely or never
> > rely on old snapshots used by new queries.
On 2020/04/14 0:15, Robert Haas wrote:
On Sun, Apr 12, 2020 at 10:09 PM Fujii Masao
wrote:
I found other minor issues.
I think these are all correct fixes. Thanks for the post-commit
review, and sorry for this mistakes.
Thanks for the review, Michael and Robert. Pushed the patches!
Hi,
On 2020-04-14 11:38:03 -0400, Robert Haas wrote:
> I'm fairly deeply uncomfortable with what Andres is proposing. I see
> that it's very powerful, and can do a lot of things, and that if
> you're building something that does sophisticated things with storage,
> you probably want an API like
Hi,
Over in [1], Tom and I had a discussion in response to some confusion
about why remove_useless_groupby_columns() goes to the trouble of
recording a dependency on the PRIMARY KEY constraint when removing
surplus columns from the GROUP BY clause.
The outcome was that we don't need to do this
At Tue, 14 Apr 2020 09:52:42 -0400, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > SyncRepGetSyncStandbysPriority() is runing holding SyncRepLock so
> > sync_standby_priority of any walsender can be changed while the
> > function is scanning welsenders. The issue is we already have
> >
On Wed, Apr 8, 2020 at 3:51 PM Mark Dilger wrote:
> Recently, as part of testing something else, I had need of a tool to create
> surgically precise corruption within heap pages. I wanted to make the
> corruption from within TAP tests, so I wrote the tool as a set of perl
> modules.
There is
Not having received any feedback on this, I've dusted the modules off for
submission as-is.
v1-0001-Adding-HeapFile-related-perl-modules.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hi David:
Thanks for your time.
> 1. Out of date comment in join.sql
>
> -- join removal is not possible when the GROUP BY contains a column that is
> -- not in the join condition. (Note: as of 9.6, we notice that b.id is a
> -- primary key and so drop b.c_id from the GROUP BY of the resulting
Alvaro Herrera writes:
> On 2020-Apr-13, Robert Haas wrote:
>> + ereport(ERROR,
>> + (errcode(ERRCODE_WRONG_OBJECT_TYPE),
>> + errmsg("action cannot be performed on relation \"%s\"",
>> + RelationGetRelationName(rel)),
>>
>> Super-vague.
> Maybe, but note that the patch proposed to replace this
Michael Paquier writes:
> On Mon, Apr 13, 2020 at 07:04:20PM -0400, Alvaro Herrera wrote:
>> I agree, I think forcing users to specify --no-manifest when run on old
>> servers will cause users to write bad scripts; I vote for silently
>> disabling checksums.
> Okay, thanks. Are there any other
On 2020-Apr-13, Robert Haas wrote:
> + ereport(ERROR,
> + (errcode(ERRCODE_WRONG_OBJECT_TYPE),
> + errmsg("action cannot be performed on relation \"%s\"",
> + RelationGetRelationName(rel)),
>
> Super-vague.
Maybe, but note that the patch proposed to replace this current error
message:
ERROR:
On Mon, Apr 13, 2020 at 07:04:20PM -0400, Alvaro Herrera wrote:
> I agree, I think forcing users to specify --no-manifest when run on old
> servers will cause users to write bad scripts; I vote for silently
> disabling checksums.
Okay, thanks. Are there any other opinions?
--
Michael
On Tue, Apr 14, 2020 at 03:13:39PM -0400, Robert Haas wrote:
> Feel free to go ahead.
Thanks, let's do it then. If you have any objections about any parts
of the patch, of course please feel free.
--
Michael
signature.asc
Description: PGP signature
On 2020-Apr-14, Michael Paquier wrote:
> On Mon, Apr 13, 2020 at 11:13:15AM -0400, Tom Lane wrote:
> > ERROR: cannot define statistics for relation "ti"
> > DETAIL: This operation is not supported for indexes.
> >
> > which still leaves implicit that "ti" is an index, but probably that's
> >
On Mon, Apr 13, 2020 at 10:13 AM Tom Lane wrote:
> As discussed in the thread at [1], I've been working on redesigning
> the tables we use to present SQL functions and operators. The
> first installment of that is now up; see tables 9.30 and 9.31 at
>
>
Andreas Joseph Krogh writes:
> Guys; This errors out with:
> ERROR: could not determine which collation to use for string comparison
> HINT: Use the COLLATE clause to set the collation explicitly.
Fixed, thanks for the report.
regards, tom lane
On Tue, Apr 14, 2020 at 10:37 AM Asif Rehman wrote:
> I forgot to make a check for no-manifest. Fixed. Attached is the updated
> patch.
+typedef struct
+{
...
+} BackupFile;
+
+typedef struct
+{
...
+} BackupState;
These structures need comments.
+list_wal_files_opt_list:
+
On 2020-Apr-14, Andrew Dunstan wrote:
> One of the things that's a bit sad is that perlcritic doesn't generally
> let you apply policies to a given set of files or files matching some
> pattern. It would be nice, for instance, to be able to apply some
> additional standards to strategic library
On 4/14/20 4:11 PM, Alvaro Herrera wrote:
On 2020-Apr-14, David Steele wrote:
Happily ISO-8601 is always UTC.
Uh, it is not --
https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators
Whoops, you are correct. I've just never seen non-UTC in the wild yet.
--
-David
da...@pgmasters.net
On 4/14/20 4:09 PM, Alvaro Herrera wrote:
> On 2020-Apr-14, Andrew Dunstan wrote:
>
>> OK, but I think if we're putting a timestamp string in ISO-8601 format
>> in the manifest it should be in UTC / Zulu time, precisely to avoid
>> these issues. If that's too much trouble then yes an epoch time
I wrote:
> It doesn't seem to me to be that hard to implement the desired
> semantics for synchronous_standby_names with inconsistent info.
> In FIRST mode you basically just need to take the N smallest
> priorities you see in the array, but without assuming there are no
> duplicates or holes. It
On 2020-Apr-14, David Steele wrote:
> Happily ISO-8601 is always UTC.
Uh, it is not --
https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-Apr-14, Andrew Dunstan wrote:
> OK, but I think if we're putting a timestamp string in ISO-8601 format
> in the manifest it should be in UTC / Zulu time, precisely to avoid
> these issues. If that's too much trouble then yes an epoch time will
> probably do.
The timestamp is always
On 4/14/20 3:55 PM, Andrew Dunstan wrote:
OK, but I think if we're putting a timestamp string in ISO-8601 format
in the manifest it should be in UTC / Zulu time, precisely to avoid
these issues. If that's too much trouble then yes an epoch time will
probably do.
Happily ISO-8601 is always
On 4/14/20 3:19 PM, David Steele wrote:
> On 4/14/20 3:03 PM, Andrew Dunstan wrote:
>>
>> On 4/14/20 1:33 PM, David Steele wrote:
>>> On 4/14/20 1:27 PM, Alvaro Herrera wrote:
On 2020-Apr-14, David Steele wrote:
> On 4/14/20 12:56 PM, Robert Haas wrote:
>
>> Hmm, did David
Hello,
I was going through some literatures on parsing CSV files in a fully
parallelized way and found (from [1]) an interesting approach
implemented in the open-source project ParaText[2]. The algorithm
follows a two-phase approach: the first pass identifies the adjusted
chunks in parallel by
On 4/14/20 3:03 PM, Andrew Dunstan wrote:
On 4/14/20 1:33 PM, David Steele wrote:
On 4/14/20 1:27 PM, Alvaro Herrera wrote:
On 2020-Apr-14, David Steele wrote:
On 4/14/20 12:56 PM, Robert Haas wrote:
Hmm, did David suggest that before? I don't recall for sure. I think
he had some
On Wed, Feb 19, 2020 at 10:05 AM Hamid Akhtar wrote:
> Attached is version 1 of POC patch for notifying of orphaned
> prepared transactions via warnings emitted to a client
> application and/or log file. It applies to PostgreSQL branch
> "master" on top of "e2e02191" commit.
I think this is a
On Mon, Apr 13, 2020 at 8:23 PM Michael Paquier wrote:
> On Mon, Apr 13, 2020 at 07:55:07PM -0400, Robert Haas wrote:
> > Oh, hmm. Maybe I'm getting confused with a previous version of the
> > patch that behaved differently.
>
> No problem. If you prefer keeping this part of the code, that's
Thanks Kyotaro and Masahiko for the feedback. I think there is a consensus on
the critical-section around truncate, but I just want to emphasize the need for
reversing the order of the dropping the buffers and the truncation.
Repro details (when full page write = off)
1) Page on disk
On 4/14/20 1:33 PM, David Steele wrote:
> On 4/14/20 1:27 PM, Alvaro Herrera wrote:
>> On 2020-Apr-14, David Steele wrote:
>>
>>> On 4/14/20 12:56 PM, Robert Haas wrote:
>>>
Hmm, did David suggest that before? I don't recall for sure. I think
he had some suggestion, but I'm not sure if
Thank you so much Bruce and Sawada.
Bruce:
I'll update the documentation with more details for max_age_prepared_xacts
Sawada:
You have raised 4 very valid points. Here are my thoughts.
(1)
I think your concern is that if we can reduce the need of 2 GUCs to one.
The purpose of having 2
On Tue, Apr 14, 2020 at 10:21 AM Tom Lane wrote:
> Awhile back I'd looked into getting rid of disable_cost altogether
> by dint of not generating disabled paths. It's harder than it
> sounds. We could perhaps change this particular case, but it's
> not clear that there's any real benefit of
On 4/14/20 1:27 PM, Alvaro Herrera wrote:
On 2020-Apr-14, David Steele wrote:
On 4/14/20 12:56 PM, Robert Haas wrote:
Hmm, did David suggest that before? I don't recall for sure. I think
he had some suggestion, but I'm not sure if it was the same one.
"I'm also partial to using epoch time
On 2020-Apr-14, David Steele wrote:
> On 4/14/20 12:56 PM, Robert Haas wrote:
>
> > Hmm, did David suggest that before? I don't recall for sure. I think
> > he had some suggestion, but I'm not sure if it was the same one.
>
> "I'm also partial to using epoch time in the manifest because it is
>
On Sun, Apr 12, 2020 at 8:09 PM Tomas Vondra
wrote:
>
> On Sun, Apr 12, 2020 at 12:44:45AM +0200, Tomas Vondra wrote:
> >Hi,
> >
> >I've looked into this a bit, and at first I thought that maybe the
> >issue is in how cost_incremental_sort picks the EC members. It simply
> >does this:
> >
> >
On 4/14/20 12:56 PM, Robert Haas wrote:
On Mon, Apr 13, 2020 at 5:43 PM Alvaro Herrera wrote:
Yeah, I guess I'm just saying that it feels brittle to have a file
format that's supposed to be good for data exchange and then make it
itself depend on representation details such as the order that
On Mon, Apr 13, 2020 at 5:43 PM Alvaro Herrera wrote:
> Yeah, I guess I'm just saying that it feels brittle to have a file
> format that's supposed to be good for data exchange and then make it
> itself depend on representation details such as the order that fields
> appear in, the letter case,
Guys; This errors out with:
ERROR: could not determine which collation to use for string comparison
HINT: Use the COLLATE clause to set the collation explicitly.
The database is init'ed with:
initdb -D $PGDATA -E utf8 --locale=nb_NO.UTF-8
13-dev HEAD as of
On Fri, 10 Apr 2020 11:00:31 +0900 (JST)
Kyotaro Horiguchi wrote:
[...]
> > > but the mistake here is it thinks that inRecovery represents whether it is
> > > running as a standby or not, but actually it is true on primary during
> > > crash recovery.
> >
> > Indeed.
> >
> > > On the other
Robert Haas writes:
> At any rate, if the price of more clarity and more examples is that
> the tables become three times as long and harder to read, I am
> somewhat inclined to think that the cure is worse than the disease. I
> can readily see how something like table 9.10 (Other String
On 4/13/20 12:47 PM, Andrew Dunstan wrote:
>
> OK, I've committed all that stuff. I think that takes care of the
> non-controversial part of what I proposed :-)
>
>
OK, it seems there is a majority of people commenting in this thread in
favor of not doing more except to reverse the policy of
On Tue, Apr 14, 2020 at 11:26 AM Tom Lane wrote:
> Well, no it isn't. The main nit I would pick in that claim is that
> it's far from obvious that the three examples of float8 * interval
> are all talking about the same operator; in fact, a reader would
> be very likely to draw the false
On 2020-04-14 12:10, Dilip Kumar wrote:
v14-0001-Immediately-WAL-log-assignments.patch +
v14-0002-Issue-individual-invalidations-with.patch +
v14-0003-Extend-the-output-plugin-API-with-stream-methods.patch+
>>I m still working on testing this patch. If anyone has Idea please
suggest.
I still see problems with this patch.
1. Variable loct have redundant initialization, it would be enough to
declare so: _locale_t loct;
2. Style white space in variable rc declaration.
3. Style variable cp_index can be
David Rowley writes:
> For testing, can't we just have an Assert() in
> advance_transition_function that verifies isnull matches the
> nullability of the return value for INTERNAL returning transfns? i.e,
> the attached
FTR, I do not like this Assert one bit. nodeAgg.c has NO business
inquiring
On Tue, Apr 14, 2020 at 11:08 AM Stephen Frost wrote:
> Wouldn't it make sense to, given that we have some idea of what we want
> it to eventually look like, to make progress in that direction though?
Well, yes. :-)
> That is- I tend to agree with Andres that having this supported
> server-side
Hi David,
On Mon, Apr 13, 2020 at 10:46 PM David Rowley wrote:
>
> On Tue, 14 Apr 2020 at 06:14, Tom Lane wrote:
> > Yeah, they're relying exactly on the assumption that nodeAgg is not
> > going to try to copy a value declared "internal", and therefore they
> > can be loosey-goosey about
Robert Haas writes:
> The v12 version of the "Table 9.30. Date/Time Operators" is not that
> wide, and is really quite clear.
Well, no it isn't. The main nit I would pick in that claim is that
it's far from obvious that the three examples of float8 * interval
are all talking about the same
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Apr 12, 2020 at 8:27 PM Andres Freund wrote:
> > I really think we want the option to eventually do this server-side. And
> > I don't quite see it as viable to go for an API that allows to specify
> > shell fragments that are
On Mon, Apr 13, 2020 at 4:29 PM Tom Lane wrote:
> I wouldn't be averse to dropping the text descriptions for operators
> in places where they seem obvious ... but who decides what is obvious?
Well, we do. We're smart, right? I don't think it's a good idea to add
clutter to table A just because
Andreas Karlsson writes:
> That said, I agree with that quite many of our tables right now are
> ugly, but I prefer ugly to hard to read. For me the mix of having every
> third row split into two fields makes the tables very hard to read. I
> have a hard time seeing which rows belong to which
On 4/14/20 4:29 PM, Tom Lane wrote:
Andreas Karlsson writes:
For the old tables I can at least just make the browser window
ridiculously wide ro read them.
A large part of the point here is to make the tables usable
when you don't have that option, as for example in PDF output.
Even with a
Amit Langote writes:
> I was really thinking of this in terms of planner effort, which for
> creating an index path is more than creating sequential path, although
> sure the payoff can be great. That is, I want the planner to avoid
> creating index paths *to save cycles*, but see no way of
Andreas Karlsson writes:
> For the old tables I can at least just make the browser window
> ridiculously wide ro read them.
A large part of the point here is to make the tables usable
when you don't have that option, as for example in PDF output.
Even with a wide window, though, some of our
Amit Langote writes:
> I am saying that instead of building index path with disabled cost,
> just don't build it at all. A base rel will always have a sequetial
> path, even though with disabled cost if enable_seqscan = off.
Awhile back I'd looked into getting rid of disable_cost altogether
by
On Tue, Apr 14, 2020 at 6:12 PM Andy Fan wrote:
> On Tue, Apr 14, 2020 at 4:58 PM Amit Langote wrote:
>> I am saying that instead of building index path with disabled cost,
>> just don't build it at all. A base rel will always have a sequetial
>> path, even though with disabled cost if
On Sun, Apr 12, 2020 at 8:27 PM Andres Freund wrote:
> > That's quite appealing. One downside - IMHO significant - is that you
> > have to have a separate process to do *anything*. If you want to add a
> > filter that just logs everything it's asked to do, for example, you've
> > gotta have a
On 4/13/20 7:13 PM, Tom Lane wrote:
As discussed in the thread at [1], I've been working on redesigning
the tables we use to present SQL functions and operators. The
first installment of that is now up; see tables 9.30 and 9.31 at
https://www.postgresql.org/docs/devel/functions-datetime.html
Kyotaro Horiguchi writes:
> SyncRepGetSyncStandbysPriority() is runing holding SyncRepLock so
> sync_standby_priority of any walsender can be changed while the
> function is scanning welsenders. The issue is we already have
> inconsistent walsender information before we enter the function. Thus
Hi ,
We have a sql file called 'generated.sql' under src/test/regress/sql
folder . if we run this file on psql , take the dump and try to restore
it on another db
we are getting error like -
psql:/tmp/x:434: ERROR: column "b" of relation "gtest1_1" is a
generated column
psql:/tmp/x:441:
Hi Asif
Getting the following error on Parallel backup when --no-manifest option is
used.
[edb@localhost bin]$
[edb@localhost bin]$
[edb@localhost bin]$ ./pg_basebackup -v -j 5 -D
/home/edb/Desktop/backup/ --no-manifest
pg_basebackup: initiating base backup, waiting for checkpoint to complete
On 4/13/20 7:55 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> On 4/13/20 7:02 PM, Jonathan S. Katz wrote:
>>> Perhaps a counterproposal: We eliminate the content in the leftmost
>>> "function column, but leave that there to allow the function name /
>>> signature to span the full 3
On Tue, Apr 14, 2020 at 3:57 PM Amit Kapila wrote:
>
> On Tue, Apr 14, 2020 at 3:41 PM Dilip Kumar wrote:
> >
> >
> > >
> > > > @@ -281,6 +281,24 @@ DecodeXactOp(LogicalDecodingContext *ctx,
> > > > XLogRecordBuffer *buf)
> > > > }
> > > > case XLOG_XACT_ASSIGNMENT:
> > > > break;
> > > >
On Tue, Apr 14, 2020 at 3:41 PM Dilip Kumar wrote:
>
>
> >
> > > @@ -281,6 +281,24 @@ DecodeXactOp(LogicalDecodingContext *ctx,
> > > XLogRecordBuffer *buf)
> > > }
> > > case XLOG_XACT_ASSIGNMENT:
> > > break;
> > > + case XLOG_XACT_INVALIDATIONS:
> > > + {
> > > + TransactionId xid;
> > >
On Tue, Apr 14, 2020 at 2:57 PM Amit Kapila wrote:
>
> On Mon, Apr 13, 2020 at 6:12 PM Kuntal Ghosh
> wrote:
> >
> > On Mon, Apr 13, 2020 at 5:20 PM Dilip Kumar wrote:
> > > On Mon, Apr 13, 2020 at 4:14 PM Kuntal Ghosh
> > > wrote:
> > > >
> > > > +#define SizeOfTransactionId
On 2020-04-11 00:44, Andres Freund wrote:
I think there's also some advantages of having it in a single statement
for poolers. If a pooler analyzes BEGIN AFTER 'xx/xx' it could
e.g. redirect the transaction to a node that's caught up far enough,
instead of blocking. But that can't work even
út 14. 4. 2020 v 11:35 odesílatel Julien Rouhaud
napsal:
> On Tue, Apr 14, 2020 at 11:25 AM Pavel Stehule
> wrote:
> >
> > út 14. 4. 2020 v 10:40 odesílatel Amit Langote
> napsal:
> >>
> >> On Tue, Apr 14, 2020 at 5:27 PM Julien Rouhaud
> wrote:
> >> > On Tue, Apr 14, 2020 at 10:18 AM Pavel
At Tue, 14 Apr 2020 13:06:14 +0900, Masahiko Sawada
wrote in
> On Tue, 14 Apr 2020 at 10:34, Tom Lane wrote:
> >
> > Kyotaro Horiguchi writes:
> > > At Sat, 11 Apr 2020 18:30:30 -0400, Tom Lane wrote in
> > >> What I think we should do about this is, essentially, to get rid of
> > >>
On Tue, Apr 14, 2020 at 11:25 AM Pavel Stehule wrote:
>
> út 14. 4. 2020 v 10:40 odesílatel Amit Langote
> napsal:
>>
>> On Tue, Apr 14, 2020 at 5:27 PM Julien Rouhaud wrote:
>> > On Tue, Apr 14, 2020 at 10:18 AM Pavel Stehule
>> > wrote:
>> > > For second run I get
>> > >
>> > > postgres=#
út 14. 4. 2020 v 10:49 odesílatel Julien Rouhaud
napsal:
> On Tue, Apr 14, 2020 at 10:36 AM Pavel Stehule
> wrote:
> >
> > út 14. 4. 2020 v 10:27 odesílatel Julien Rouhaud
> napsal:
> >>
> >> Hi,
> >>
> >> On Tue, Apr 14, 2020 at 10:18 AM Pavel Stehule
> wrote:
> >> >
> >> > Hi
> >> >
> >> >
On Mon, Apr 13, 2020 at 6:12 PM Kuntal Ghosh wrote:
>
> On Mon, Apr 13, 2020 at 5:20 PM Dilip Kumar wrote:
> > On Mon, Apr 13, 2020 at 4:14 PM Kuntal Ghosh
> > wrote:
> > >
> > > +#define SizeOfTransactionId (sizeof(TransactionId) + sizeof(char))
> > > This looks wrong. We should change the
út 14. 4. 2020 v 10:40 odesílatel Amit Langote
napsal:
> On Tue, Apr 14, 2020 at 5:27 PM Julien Rouhaud wrote:
> > On Tue, Apr 14, 2020 at 10:18 AM Pavel Stehule
> wrote:
> > > For second run I get
> > >
> > > postgres=# EXPLAIN (BUFFERS, ANALYZE) SELECT * FROM obce WHERE
> okres_id =
On Tue, Apr 14, 2020 at 5:12 PM Andy Fan wrote:
>
>
> On Tue, Apr 14, 2020 at 4:58 PM Amit Langote
> wrote:
>
>> On Tue, Apr 14, 2020 at 5:29 PM Andy Fan
>> wrote:
>> > On Tue, Apr 14, 2020 at 3:40 PM Amit Langote
>> wrote:
>> >> On Tue, Apr 14, 2020 at 4:13 PM Richard Guo
>> wrote:
>> >> >
On Wed, 8 Apr 2020 at 07:40, Dmitry Dolgov <9erthali...@gmail.com> 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
On Tue, Apr 14, 2020 at 4:58 PM Amit Langote
wrote:
> On Tue, Apr 14, 2020 at 5:29 PM Andy Fan wrote:
> > On Tue, Apr 14, 2020 at 3:40 PM Amit Langote
> wrote:
> >> On Tue, Apr 14, 2020 at 4:13 PM Richard Guo
> wrote:
> >> > On Tue, Apr 14, 2020 at 2:44 PM Amit Langote
> wrote:
> >> >> Maybe
On Fri, 3 Apr 2020 at 15:18, Andy Fan wrote:
> All above 4 item Done.
Just to explain my view on this going forward for PG14. I do plan to
do a more thorough review of this soon. I wasn't so keen on pursuing
this for PG13 as the skip scans patch [1] needs to use the same
infrastructure this
Hello,
On Mon, Apr 13, 2020 at 4:04 PM Patrick REED wrote:
>
> I am experimenting with postgres and am wondering if there is any tutorial on
> how to properly add a new command to postgres.
>
> I want to add a new constraint on "CREATE ROLE" that requires an integer, it
> has an identifier
On Tue, Apr 14, 2020 at 5:29 PM Andy Fan wrote:
> On Tue, Apr 14, 2020 at 3:40 PM Amit Langote wrote:
>> On Tue, Apr 14, 2020 at 4:13 PM Richard Guo wrote:
>> > On Tue, Apr 14, 2020 at 2:44 PM Amit Langote
>> > wrote:
>> >> Maybe I am missing something obvious, but is it intentional that
>>
On Tue, Apr 14, 2020 at 10:40 AM Amit Langote wrote:
>
> On Tue, Apr 14, 2020 at 5:27 PM Julien Rouhaud wrote:
> > On Tue, Apr 14, 2020 at 10:18 AM Pavel Stehule
> > wrote:
> > > For second run I get
> > >
> > > postgres=# EXPLAIN (BUFFERS, ANALYZE) SELECT * FROM obce WHERE okres_id =
> > >
On Tue, Apr 14, 2020 at 10:36 AM Pavel Stehule wrote:
>
> út 14. 4. 2020 v 10:27 odesílatel Julien Rouhaud napsal:
>>
>> Hi,
>>
>> On Tue, Apr 14, 2020 at 10:18 AM Pavel Stehule
>> wrote:
>> >
>> > Hi
>> >
>> > I am testing some features from Postgres 13, and I am not sure if I
>> >
On Tue, Apr 14, 2020 at 5:27 PM Julien Rouhaud wrote:
> On Tue, Apr 14, 2020 at 10:18 AM Pavel Stehule
> wrote:
> > For second run I get
> >
> > postgres=# EXPLAIN (BUFFERS, ANALYZE) SELECT * FROM obce WHERE okres_id =
> > 'CZ0201';
> >
út 14. 4. 2020 v 10:27 odesílatel Julien Rouhaud
napsal:
> Hi,
>
> On Tue, Apr 14, 2020 at 10:18 AM Pavel Stehule
> wrote:
> >
> > Hi
> >
> > I am testing some features from Postgres 13, and I am not sure if I
> understand well to behave of EXPLAIN(ANALYZE, BUFFERS)
> >
> > When I run following
On Tue, Apr 14, 2020 at 3:40 PM Amit Langote
wrote:
> On Tue, Apr 14, 2020 at 4:13 PM Richard Guo
> wrote:
> > On Tue, Apr 14, 2020 at 2:44 PM Amit Langote
> wrote:
> >> Maybe I am missing something obvious, but is it intentional that
> >> enable_indexscan is checked by cost_index(), that is,
Hi,
On Tue, Apr 14, 2020 at 10:18 AM Pavel Stehule wrote:
>
> Hi
>
> I am testing some features from Postgres 13, and I am not sure if I
> understand well to behave of EXPLAIN(ANALYZE, BUFFERS)
>
> When I run following statement first time in session I get
>
> postgres=# EXPLAIN (BUFFERS,
Hi
I am testing some features from Postgres 13, and I am not sure if I
understand well to behave of EXPLAIN(ANALYZE, BUFFERS)
When I run following statement first time in session I get
postgres=# EXPLAIN (BUFFERS, ANALYZE) SELECT * FROM obce WHERE okres_id =
'CZ0201';
On Tue, Apr 14, 2020 at 4:13 PM Richard Guo wrote:
> On Tue, Apr 14, 2020 at 2:44 PM Amit Langote wrote:
>> Maybe I am missing something obvious, but is it intentional that
>> enable_indexscan is checked by cost_index(), that is, *after* creating
>> an index path? I was expecting that if
On Fri, Apr 10, 2020 at 5:33 PM Amit Kapila wrote:
>
> It seems the right direction to use GetLocaleInfoEx as we have already
> used it to handle a similar problem (lc_codepage is missing in
> _locale_t in higher versions of MSVC (cf commit 0fb54de9aa)) in
> chklocale.c. However, I see that we
On 2020-03-30 20:10, Andres Freund wrote:
Also, shouldn't dynahash be adjusted as well? There's e.g. the
following HASH_ENTER path:
/* report a generic message */
if (hashp->isshared)
On Tue, Apr 14, 2020 at 2:44 PM Amit Langote
wrote:
> Hi,
>
> Maybe I am missing something obvious, but is it intentional that
> enable_indexscan is checked by cost_index(), that is, *after* creating
> an index path? I was expecting that if enable_indexscan is off, then
> no index paths would
1 - 100 of 103 matches
Mail list logo
