t ensure that when we commit
>> something, all the preceding WAL is
>> "complete" (i.e. written by other backends etc.)?
>
> To wait for *all* the WALInsertLocks to be released, no matter each of
> them precedes or follows the current insertion.
>
> It would have wo
ows?
This makes the code rather hard to read, IMHO. It seems to me we can
move the code around a bit and merge some of the #ifdef blocks - see the
attached patch. Most of this is fairly trivial, with the exception of
moving PrefetchBuffer before table_scan_analyze_next_block - AFAIK this
e the GUC to remove_temp_files_after_crash, I think
"remove" is a bit clearer than "cleanup". I've also reworded the sgml
docs a little bit.
Attached is a patch with those changes. Barring objections, I'll get
this committed in the next couple days.
regards
On 3/9/21 9:51 PM, John Naylor wrote:
>
> On Sun, Mar 7, 2021 at 8:53 PM Tomas Vondra
> mailto:tomas.von...@enterprisedb.com>>
> wrote:
> [v20210308b]
>
> I managed to trap an assertion that somehow doesn't happen during the
> regression tests. The caller
ping pathkeys (as specified in the
query), and the "optimal" pathkeys (by lowest cost).
* the places calling group_keys_reorder_by_pathkeys should loop on the
result, and generate separate path for each option.
I'd guess in the future we'll "peek forward" in the plan a
is the suggestion based on X runs) we could have a view or
something. This would also work for read-only replicas, where just
creating the statistics is impossible.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 3/8/21 8:42 PM, Stephen Frost wrote:
> Greetings,
>
> * Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
>> On 2/10/21 11:10 PM, Stephen Frost wrote:
>>> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>>>> On 05/02/2021 23:22, Stephen Frost wrote:
>&g
On 3/10/21 3:00 AM, Tomas Vondra wrote:
> Hello Konstantin,
>
>
> Sorry for not responding to this thread earlier. I definitely agree the
> features proposed here are very interesting and useful, and I appreciate
> you kept rebasing the patch.
>
> I think the patch impr
equire some improvements to the extended statistics code (to
allow passing a list of conditions), but that's quite doable. I think
the code actually did something like that originally ;-)
Obviously, none of this is achievable for PG14, as we're in the middle
of the last CF. But if
ricky
to get right.
(Of course, there are cases where you may get such queries even if you
try writing good SQL, say when joining views etc.)
regards
[1]
https://www.postgresql.org/message-id/flat/64486b0b-0404-e39e-322d-080115490...@postgrespro.ru
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 3/12/21 1:11 AM, Stephen Frost wrote:
> Greetings,
>
> * Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
>> On 3/8/21 8:42 PM, Stephen Frost wrote:
>>> * Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
>>>> On 2/10/21 11:10 PM, Stephen Frost wrot
ion tomorrow. Thanks for the nudge and the review.
>
So, is it tomorrow already? ;-)
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
emory is consumed
on the server.
With this pg_dump patch, the compression is done by the pg_dump process,
not the server. So if the attacker configures the compression in a way
that requires a lot of memory, so what? He'll just allocate memory on
the client machine, where he could also just run a custom binary that
does a huge malloc().
So I don't think we need to worry about this too much.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
roduce a struct with
two fields, and just use that. Not sure how invasive that will be
outside gram.y, though.
Also, the all_or_distinct vs. distinct_or_all seems a bit error-prone. I
wonder if we can come up with some clearer names, describing the context
of those types.
regards
--
Tomas Vond
On 3/16/21 9:21 AM, Vik Fearing wrote:
> On 3/13/21 12:33 AM, Tomas Vondra wrote:
>> Hi Vik,
>>
>> The patch seems quite ready, I have just two comments.
>
> Thanks for taking a look.
>
>> 1) Shouldn't this add another for DISTINCT, somewhere in t
ng in the
first patch, and the more advanced stuff in additional patches.
Does that make sense?
regards
[1]
https://www.postgresql.org/message-id/20200901210743.lutgvnfzntvhuban%40development
[2]
https://www.postgresql.org/message-id/20200516145609.vm7nrqy7frj4ha6r%40development
--
Tomas Von
, it doesn't produce any visible
plan changes.) I'm a little nervous about whether the plan
shape will be stable in the buildfarm, but it works for me on
both 64-bit and 32-bit machines, so probably it's OK.
Works fine on raspberry pi 4 (i.e. armv7l, 32-bit arm) too.
regards
tuning
logical_decoding_work_mem.
Now that I look again, maybe remove "accordingly" ?
Yeah, the 'accordingly' seems rather unnecessary here. Let's remove it.
FWIW thanks to everyone working on this and getting the reworked version
of the 9290ad198b patch in. As
s thread, so it's a bit hand-wavy. Can someone share details
of such workload (even synthetic one) and some basic measurements?
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Oct 27, 2020 at 09:27:06PM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Tue, Oct 27, 2020 at 01:58:56PM -0400, Tom Lane wrote:
Attached is a patch series that attacks it that way.
The patch sems fine to me, thanks for investigating and fixing this.
Thanks for looking at it!
I
I'd try
to create a couple examples (CREATE TABLE + SELECT + EXPLAIN) showing
how the patch changes the query plan, showing speedup etc.
I'd like to do a review and some testing, and this would make it much
easier for me.
kind regards
--
Tomas Vondra http://www.2ndQua
have a very good justification for the alternative
other than vague personal preference.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
't notice that for an index. So if
the table does not change very often, it may take ages before we build
stats for the index - not great.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
idated) index doesn't
have statistics of its own isn't a problem in my book.
I agree the lack of stats may be quite annoying and cause issues, but my
guess is the chances of backpatching such change are about 0.01%. We
have a usable 'workaround' for this - manual analyze.
compression methods, we can not support
dictionary-based options as of now.
OK, thanks. Do you have any other plans to improve this patch series? I
plan to do some testing and review, but if you're likely to post another
version soon then I'd wait a bit.
regards
--
To
;s an interesting / useful information, I'd keep it (in the
\dX+ output only, of course). But I think it needs to print the size
similarly to \d+, i.e. using pg_size_pretty - that'll include the unit
and make it more readable for large stats.
regards
--
Tomas Vondra http://www.
rdering of
result was wrong so I fixed on the attached patch.
Please fined the patch file. :-D
Thanks. I'll take a look at the beginning of the 2020-11 commitfest, and
I hope to get this committed.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Developmen
On Wed, Oct 28, 2020 at 12:00:54PM -0700, David G. Johnston wrote:
On Wed, Oct 28, 2020 at 11:55 AM Tomas Vondra
wrote:
I agree the lack of stats may be quite annoying and cause issues, but my
guess is the chances of backpatching such change are about 0.01%. We
have a usable 'worka
On Wed, Oct 28, 2020 at 03:05:39PM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Mon, Oct 26, 2020 at 03:46:10PM -0700, David G. Johnston wrote:
It would seem preferable to call the lack of auto-analyzing after these
operations a bug and back-patch a fix that injects an analyze side-effect
On Wed, Oct 28, 2020 at 03:18:52PM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Wed, Oct 28, 2020 at 12:00:54PM -0700, David G. Johnston wrote:
Given how simple the manual workaround is not having it be manual seems
like it would be safe and straight-forward to implement.
Maybe, but I
On Wed, Oct 28, 2020 at 05:43:08PM -0300, Fabrízio de Royes Mello wrote:
On Wed, Oct 28, 2020 at 4:35 PM Tomas Vondra
wrote:
I don't think anyone proposed to do this through autovacuum. There was a
reference to auto-analyze but I think that was meant as 'run analyze
automatical
On Wed, Oct 28, 2020 at 10:36:39PM +0300, Alexander Korotkov wrote:
Hi, Tomas!
Thank you for your review.
On Wed, Oct 28, 2020 at 4:36 AM Tomas Vondra
wrote:
I did a quick review on this patch series. A couple comments:
0001
This looks quite suspicious to me
Hi,
On Wed, Oct 28, 2020 at 12:34:58PM +0500, Andrey Borodin wrote:
Tomas, thanks for looking into this!
28 окт. 2020 г., в 06:36, Tomas Vondra
написал(а):
This thread started with a discussion about making the SLRU sizes
configurable, but this patch version only adds a local cache. Does
ing on this
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Oct 29, 2020 at 12:08:21PM +0500, Andrey Borodin wrote:
29 окт. 2020 г., в 04:32, Tomas Vondra
написал(а):
It's not my intention to be mean or anything like that, but to me this
means we don't really understand the problem we're trying to solve. Had
we understood i
inue;
Isn't this missing the second bms_is_empty condition?
Of course, an alternative to this fix would be reverting ba3e76cc571
(completely or just the part introducing generate_useful_gather_paths).
If anyone thinks that's what we should do, please speak now.
regards
--
Toma
the
blocks added to hio.c. IMO it's sufficient to use HEAP_INSERT_FROZEN in
the condition, at this level of abstraction.
I wonder what to do about the heap_insert - I know there are concerns it
would negatively impact regular insert, but is it really true? I suppose
this optimization would be v
data where a fields may span multiple 64kB
blocks and may contain newlines etc.
The non-parallel copy works fine, the parallel one fails. I haven't
investigated the details, but I guess it gets confused about where a
string starts/end, or something like that.
[1] https://github.com/tvondra/random
PROCESSING
Of course, the question is whether parsing really is sufficiently
expensive for this to be worth it.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Oct 30, 2020 at 01:26:08PM -0400, James Coleman wrote:
On Thu, Oct 29, 2020 at 6:06 PM Tomas Vondra
wrote:
On Tue, Oct 06, 2020 at 09:37:31AM -0400, James Coleman wrote:
>On Tue, Oct 6, 2020 at 9:28 AM Jaime Casanova
> wrote:
>> Can you please create an entry in the co
Esteban! I'll do a bit more
review next week, and I'll see if I can get it committed.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 414aefb911308b39ffefbd2190db66f2ee24c26c Mon Sep 17 0
I understand what would be the risk with this ... Tom,
can you elaborate why you dislike the patch?
BTW we already have a way to improve the estimate - setting n_distinct
for the column to 1.0 using ALTER TABLE should do the trick, I think.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
simply don't support
passing partial results to the leader, hence combine/serial/deserial
functions are not needed.
Not sure about the direct arguments.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ult we'd not collect/print this, and users would have to
pass some option to EXPLAIN. Or maybe we could tie this to VERBOSE?
Also, why print this only for nested loop, and not for all nodes with
(nloops > 1)? I see there was some discussion why checking nodeTag is
necessary to identify
;re dealing with (internal/leaf)
to the place actually calling pgstat_count_buffer_(read|hit). That
happens in ReadBufferExtended, which just has no idea what page it's
dealing with. Not sure how to do that cleanly ...
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sat, Oct 31, 2020 at 12:09:32AM +0200, Heikki Linnakangas wrote:
On 30/10/2020 22:56, Tomas Vondra wrote:
I agree this design looks simpler. I'm a bit worried about serializing
the parsing like this, though. It's true the current approach (where the
first phase of parsing happ
On Mon, Nov 02, 2020 at 04:44:22PM +0300, Anastasia Lubennikova wrote:
On 30.10.2020 03:42, Tomas Vondra wrote:
Hi,
I might be somewhat late to the party, but I've done a bit of
benchmarking too ;-) I used TPC-H data from a 100GB test, and tried
different combinations of COPY [FREEZE
oth the FDW and allpaths.c, but now that the functions
diverged it's only called from the FDW again. So maybe we should move
it back, but I guess that's not a good thing in a minor release.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x
patch. So that's a third data type ...
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 43545ab6e54821a1d459cde2ff9dea58ece2c237 Mon Sep 17 00:00:00 2001
From: tanghy
Date: Fri, 16 Oct 2020 14:
On Tue, Nov 03, 2020 at 03:37:43AM +0100, Tomas Vondra wrote:
On Fri, Oct 30, 2020 at 07:37:33PM -0400, James Coleman wrote:
...
I was looking at this some more, and I'm still convinced that this is
correct, but I don't think a comment about it being an optimization
(though I su
On Tue, Nov 03, 2020 at 03:53:53AM +0100, Tomas Vondra wrote:
Hi,
I took another look at this, and 99% of the patch (the fixes to sort
debug messages) seems fine to me. Attached is the part I plan to get
committed, including commit message etc.
I've pushed this part. Thanks for the
ssage-id/20201001184133.oq5uq75sb45pu3aw%40development
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/access/brin/brin_tuple.c
b/src/backend/access/brin/brin_tuple.c
index 46e6b23c87..96e
helpful that is, it probably does
not say much about how we got there.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) a
On Wed, Nov 04, 2020 at 02:49:24PM +1300, Thomas Munro wrote:
On Wed, Nov 4, 2020 at 2:32 PM Tomas Vondra
wrote:
After a while (~1h on my machine) the pg_multixact gets over 10GB, which
triggers a more aggressive cleanup (per MultiXactMemberFreezeThreshold).
My guess is that this discards some
On Wed, Nov 04, 2020 at 05:36:46PM +1300, Thomas Munro wrote:
On Wed, Nov 4, 2020 at 2:57 PM Tomas Vondra
wrote:
On Wed, Nov 04, 2020 at 02:49:24PM +1300, Thomas Munro wrote:
>On Wed, Nov 4, 2020 at 2:32 PM Tomas Vondra
> wrote:
>> After a while (~1h on my machine) the pg_multixa
ocks.
BTW it seems your e-mail client does something funny, stripping the
"references" headers, which breaks threading and makes following the
discussion very hard (and will confuse the CF app too). If you look at
pgsql-hackers archives, each of your responses starts a new thread.
regards
Hi,
On 11/4/20 5:02 PM, Stephen Frost wrote:
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
If you highlight "738754560" in the output it appears to duplicate the
syscalls issued until it preads() - in case of "738754560" offset it was
asked for 3 ti
On 11/4/20 10:58 PM, David Rowley wrote:
On Wed, 4 Nov 2020 at 10:42, Tomas Vondra wrote:
IMHO this should simply switch the current int64 variable to long, as it
was before. Not sure about about the hashagg uint64 variable.
IMO, we should just get rid of the use of "long" here
On 11/4/20 2:05 AM, Tomas Vondra wrote:
Hi,
As pointed out in [1], BRIN is not properly handling toasted data, which
may easily lead to index tuples referencing TOAST-ed values. Which is
clearly wrong - it's trivial to trigger failues after a DELETE.
Attached is a patch that aims to fix
On 11/4/20 2:50 PM, Tomas Vondra wrote:
On Wed, Nov 04, 2020 at 05:36:46PM +1300, Thomas Munro wrote:
On Wed, Nov 4, 2020 at 2:57 PM Tomas Vondra
wrote:
On Wed, Nov 04, 2020 at 02:49:24PM +1300, Thomas Munro wrote:
>On Wed, Nov 4, 2020 at 2:32 PM Tomas Vondra
> wrote:
>> After a w
On 11/5/20 6:17 PM, Alvaro Herrera wrote:
On 2020-Nov-04, Tomas Vondra wrote:
The first test is fairly trivial - it simply builds index on toasted data
and then shows how an insert and select fail. There's a caveat, that this
requires a DELETE + VACUUM, and the VACUUM actually h
On Thu, 5 Nov 2020 18:16:04 -0300
Alvaro Herrera wrote:
> On 2020-Nov-05, Tomas Vondra wrote:
>
> > On 11/5/20 6:17 PM, Alvaro Herrera wrote:
>
> > > There are recent changes in vacuum for temp tables (commit
> > > 94bc27b57680?) that would maybe make this st
bout the BRIN
data corruption fixed by 7577dd8480 - a query to list might be
affected by the bug and should be rebuilt.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hi,
On 11/7/20 3:52 AM, Tom Lane wrote:
> Tomas Vondra writes:
>> We should probably include instructions what to do about the BRIN
>> data corruption fixed by 7577dd8480 - a query to list might be
>> affected by the bug and should be rebuilt.
>
> Do you have some
On 11/7/20 11:21 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> On 11/7/20 3:52 AM, Tom Lane wrote:
>>> Do you have some suggested text?
>
>> I think this might work:
>
> I dunno ... given that we have zero field reports, I doubt this is
> something we need
l get the attached fix committed and backpatched.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
>From d97e3160921caa6d2191b7e8539d4d4f4816219c Mon Sep 17 00:00:00 2001
From: Tomas Vondra
Date: Sun, 8 Nov 2020 02:11:45 +0100
Subject: [PATCH
t suggesting I'll push
this right away. Or at least I did not mean to. Sorry if that was not
quite clear.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ended statistics. So
depending on the timing the \dX may list some of the stats_ext stuff.
I'm not sure what to do about this. Either this part needs to be moved
to a separate test executed in a different group, or maybe we should
simply move it to stats_ext.
regards
--
Tomas
On 11/9/20 3:29 PM, John Naylor wrote:
> On Sat, Nov 7, 2020 at 4:38 PM Tomas Vondra
> mailto:tomas.von...@enterprisedb.com>>
> wrote:
>
>> Overall, I think there's very little difference, particularly in the
>> "match" cases when we're sea
On 11/9/20 7:06 PM, Stephen Frost wrote:
> Greetings,
>
> * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
>> On 11/4/20 5:02 PM, Stephen Frost wrote:
>>> * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
>>>>> If you highlight "73875456
stgresql.org/message-id/20201104013205.icogbi773przyny5@development
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
a small
subset, not all partitions may be foreign, etc. It seems pretty
difficult to pick and enforce a reliable limit at the query level. But
maybe I'm missing something and it's easier than I think?
Of course, you're entirely correct enforcing this at the partition level
may require a lot of memory. Sadly, I don't see a way around that,
except for (a) disabling batching or (b) ordering the data to insert
data into one partition at a time.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 11/10/20 4:05 PM, Tomas Vondra wrote:
> Hi,
>
> Thanks for working on this!
>
> On 11/10/20 1:45 AM, tsunakawa.ta...@fujitsu.com wrote:
>> Hello,
>>
>>
>> The attached patch implements the new bulk insert routine for
>> postgres_fdw and the ex
;> But (partition_prune) persists.
>> partition_prune ... FAILED
>>
>> regards,
>> Ranier Vilela
>
> I am also experiencing this issue on one of my Windows machines (x64)
> using 12.4. I believe this is new, possibly since 12.2. It doesn't
> occur on another machine though, which is strange. It appears to be
> the same diff output. Is it possible that the given result is also
> valid for this test?
>
That's unlikely, I think. The regression tests are constructed so that
the estimates are stable. It's more likely this is some difference in
rounding behavior, for example. I wonder which msvc builds are used on
the machines that fail/pass the tests, and if the compiler flags are the
same.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 11/10/20 7:16 AM, Andrey Borodin wrote:
>
>
>> 10 нояб. 2020 г., в 05:13, Tomas Vondra
>> написал(а):
>> After the issue reported in [1] got fixed, I've restarted the multi-xact
>> stress test, hoping to reproduce the issue. But so far no luck :-(
>
Hi,
I needed to look at this patch while working on something related, and I
found it got broken by 6973533650c a couple days ago. So here's a fixed
version, to keep cfbot happy. I haven't done any serious review yet.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprise
On 11/10/20 7:15 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> That's unlikely, I think. The regression tests are constructed so that
>> the estimates are stable. It's more likely this is some difference in
>> rounding behavior, for example.
>
> The repo
pagetable_create, but the crashes are much more common.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Core was generated by `postgres: postgres test [local] SELECT
'.
Program terminated with signal S
ions.
Ultimately, this should probably do the same thing as 0002 and add thin
wrappers, because the existing functions are part of the public API.
Dean, does this address the issue you had in mind? Can you come up with
an example of that issue in the form of a regression test or something?
regard
columnstore features down the road will be execution on
compressed data, which however requires compression method designed for
that purpose, and it's often datatype-specific (delta encoding, ...).
I don't think we need to go as far as supporting "custom" compression
methods her
nsional histograms to address the second one).
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
>From 439d39db128b9cbc06063a862283d663510d0fcc Mon Sep 17 00:00:00 2001
From: Tomas Vondra
Date: Fri, 13 Nov 2020 01:46:50 +0100
Subject: [PATCH] Sup
ting it - if the
prefetch can't work because of blocking restore script, someone has to
fix/improve the script. No way around that, I'm afraid.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 11/13/20 8:07 PM, Jacob Champion wrote:
> On Nov 12, 2020, at 2:40 PM, Tomas Vondra
> wrote:
>>
>> Hi,
>>
>> Thanks for the updated patch. It's a quite massive amount of code - I I
>> don't think we had many 2MB patches in the past, so this is
that I don't
see for some reason.
The one remaining thing I'm not sure about is naming of the columns with
size of statistics - N_size, D_size and M_size does not seem very clear.
Any clearer naming will however make the tables wider, though :-/
regards
--
Tomas Vondra
EnterpriseDB: h
On 11/16/20 2:49 PM, Tomas Vondra wrote:
> Hi,
>
> ...
>
> 4) apply the statistics
>
>This is the hard part, really, and the exact state of the support
>depends on type of statistics.
>
>For ndistinct coefficients, it generally works. I&#x
On 11/16/20 1:59 PM, Merlin Moncure wrote:
> On Thu, Nov 12, 2020 at 4:40 PM Tomas Vondra
> wrote:
>>masterzedstore/pglzzedstore/lz4
>> -
>>copy 1855680922
On 1/15/20 12:44 AM, Tom Lane wrote:
> Tomas Vondra writes:
>> On Tue, Jan 14, 2020 at 05:37:53PM -0500, Tom Lane wrote:
>>> I wonder just how messy it would be to add a column to pg_statistic_ext
>>> whose type is the composite type "pg_statistic", and
ossible consequences.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
index 84a69b064a..93db261011 100644
--- a/src/backend/optimizer/path/allpaths.c
+++ b/s
On 11/17/20 3:03 PM, James Coleman wrote:
> On Mon, Nov 16, 2020 at 11:23 PM Tomas Vondra
> wrote:
>>
>> Hmm, I missed that other thread. That indeed seems like a bug in the
>> same area already tweaked by ebb7ae839d033d0f2 for similar cases.
>
> I meant to bri
On 11/17/20 5:18 PM, Justin Pryzby wrote:
> On Mon, Nov 16, 2020 at 06:24:41PM +0100, Tomas Vondra wrote:
>> On 1/15/20 12:44 AM, Tom Lane wrote:
>>> Tomas Vondra writes:
>>>> On Tue, Jan 14, 2020 at 05:37:53PM -0500, Tom Lane wrote:
>>>>> I wonder
with the parameter lists.
A finally, this should probably add a bunch of regression tests.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
>From 6a7031c800dff8fff9e1e64e0278494f3acd686f Mon Sep 17 00:00:00 2001
From: Takayuki Tsunakawa
Date: Tu
On 11/17/20 4:35 PM, Dean Rasheed wrote:
> On Thu, 12 Nov 2020 at 14:18, Tomas Vondra
> wrote:
>>
>> Here is an improved WIP version of the patch series, modified to address
>> the issue with repeatedly applying the extended statistics, as discussed
>> with D
On 11/19/20 3:43 AM, tsunakawa.ta...@fujitsu.com wrote:
> From: Tomas Vondra
>> Unfortunately, this does not compile for me, because
>> nodeModifyTable calls ExecGetTouchedPartitions, which is not
>> defined anywhere. Not sure what's that about, so I simply
>> c
gather_merge_path() with pathkeys matching the
subpath. And it's like that on REL_12_STABLE too, i.e. before the
incremental sort was introduced.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ere).
>
Yeah. I think the various FDW-related restrictions may easily make that
safe, for the reasons you already mentioned. But also because IIRC FDWs
in general are not parallel-safe, so there's no risk of running foreign
scans under Gather [Merge].
Thanks for the patches, I'll take a closer look next week. The 0002
patch is clearly something we need to backpatch, not sure about 0001 as
it essentially enables new behavior in some cases (Sort on unsorted
paths below Gather Merge).
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 11/22/20 10:31 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> On 11/20/20 11:24 PM, James Coleman wrote:
>>> While looking at another issue I noticed that create_gather_merge_plan
>>> calls make_sort if the subplan isn't sufficiently sorted. In all of
>&g
em nice. It's interesting the patched case is a
bit slower than master. Not sure why.
Overall, these results seem pretty nice, I guess. Of course, this does
not say the current patch is the best way to implement this (or whether
it's correct), but it does suggest supporti
, without
writing that to the WAL segments at all (unless in archiving mode)?
Firstly, I guess many (most?) instances will have to write the WAL
segments anyway because of PITR/backups, so I'm not sure we can save
much here.
But more importantly - doesn't that mean the nvwal_size value is
On 11/23/20 3:26 AM, Justin Pryzby wrote:
> On Sun, Nov 22, 2020 at 08:03:51PM +0100, Tomas Vondra wrote:
>> attached is a significantly improved version of the patch, allowing
>> defining extended statistics on expressions. This fixes most of the
>> problems in the pre
Hi,
On 11/23/20 3:01 AM, Tomas Vondra wrote:
> Hi,
>
> On 10/30/20 6:57 AM, Takashi Menjo wrote:
>> Hi Heikki,
>>
>>> I had a new look at this thread today, trying to figure out where
>>> we are.
>>
>> I'm a bit confused.
>>>
>
101 - 200 of 3960 matches
Mail list logo
