gather node? or
other ways to get around?
Thank you,
Donald Dong
,
standard_join_search is doing a complete search. So I'm not sure how the GEQO
managed to do better than that.
Thank you,
Donald Dong
der why those two total costs are different? If the total_cost
from the planstate is more accurate, could we use that instead as the
fitness in geqo_eval?
[1] https://github.com/gregrahn/join-order-benchmark
Regards,
Donald Dong
> On May 7, 2019, at 4:44 PM, Tom Lane wrote:
>
> Donald
On May 22, 2019, at 11:42 AM, Tom Lane wrote:
>
> Donald Dong writes:
>> I find the cost from cheapest_total_path->total_cost is different
>> from the cost from queryDesc->planstate->total_cost. What I saw was
>> that GEQO tends to form paths with lower
>&g
On May 23, 2019, at 9:02 AM, Tom Lane wrote:
>
> Donald Dong writes:
>> On May 22, 2019, at 11:42 AM, Tom Lane wrote:
>>> You're still asking us to answer hypothetical questions unsupported
>>> by evidence. In what case does that really happen?
On May 23, 2019, at 10:43 AM, Tom Lane wrote:
> Donald Dong writes:
>> On May 23, 2019, at 9:02 AM, Tom Lane wrote:
>>> (2) the paths you show do not correspond to the finally selected
>>> plans --- they aren't even the same shape. (The Gathers are in
>>&g
ing this observation, and how to get estimations close to the
final plan?
Thank you,
Donald Dong
've thought about it
about more before posting here. Thank you for answering this
question!
Regards,
Donald Dong
lType case in print_expr. After
the patch, I get:
RELOPTINFO (tbl_a): rows=4 width=86
baserestrictinfo: tbl_a.info = pattern
I wonder if this is a proper way of fixing it?
Thank you,
Donald Dong
001_print_baserestrictinfo_varchar.patch
Description: Binary data
b0b39f72b9904bcb80f97b35837ccff1578aa4b8. I wonder if
this only occurs to me?
Thank you,
Donald Dong
x27;s path fixes it.
Regards,
Donald Dong
> On Jan 18, 2019, at 2:05 AM, Andrew Gierth
> wrote:
>
> BTW, doing that in a thread about a commitfest patch confuses the
> commitfest app and cfbot (both of which think it's a new version of the
> patch under discussion), so best avoided.
Oops. Thank you. Noted.
I think the previous addit
> On Jan 19, 2019, at 5:12 PM, Andrew Gierth
> wrote:
>
>>>>>> "Donald" == Donald Dong writes:
>
> Donald> I think the previous additional digits behavior still exist
> Donald> in the latest patch. For example:
>
> Donald> =#
emmer tsearch \
tsearch/dicts utils port port/atomics port/win32 port/win32_msvc \
Regards,
Donald Dong
I need to be
aware, to execute a plan in the child process and report the
result in the parent process?
What do you think? I will appreciate any feedback.
Thank you,
Donald Dong
On Jan 23, 2019, at 6:46 AM, Tom Lane wrote:
>
> Oleksandr Shulgin writes:
>> On Wed, Jan 23, 2019 at 9:44 AM Donald Dong wrote:
>>> 1. Enumerate all the plans
>
>> So enumerating all possible plans stops being practical for even slightly
>> complica
tween time and cost. Would
it be a feature worth considering?
Thank you,
Donald Dong
loops=3)
Now we have the actual time. Time can have a high variance (a change
in system load, or just noises), but I think the actual cost would be
less likely to change due to external factors.
On 2/17/19 3:40 AM, David Fetter wrote:
> On Sat, Feb 16, 2019 at 03:10:44PM -0800, Donald Dong wrote:
>
On Feb 16, 2019, at 9:31 PM, Tom Lane wrote:
>
> Donald Dong writes:
>> On Feb 16, 2019, at 6:44 PM, Tomas Vondra wrote:
>>> I don't quite understand what is meant by "actual cost metric" and/or
>>> how is that different from running EXPLAIN ANALY
ost" is only "actual" for the cost model - the cost
it would output given the exact row/page number. Some articles/papers have
shown row estimation is the primary reason for planners to go off, so showing
the actual (or the updated assumption) might also be useful if people want to
compare different plans and want to refer to a more accurate quantitative
measure.
regards,
Donald Dong
On Feb 17, 2019, at 11:05 AM, Donald Dong wrote:
>
> On Feb 17, 2019, at 10:56 AM, Tom Lane wrote:
>> Perhaps, but refactoring to get that seems impractically invasive &
>> expensive, since e.g. index AM cost estimate functions would have to
>> be redefined, plus we
-enable-new-dtags
Then the make command works as expected. This is my first time writing
a patch. Please let me know what you think!
Thank you,
Happy new year!
Donald Dong
On Mon, Dec 31, 2018 at 11:24 PM Donald Dong wrote:
>
> Hi,
>
> In src/test/example, the implicit make rules produce errors:
>
> make -C ../../../src/backend generated-headers
> make[1]: Entering directory '/home/ddong/postgresql/bld/src/backend'
> make -C
ion:
GNU ld (GNU Binutils for Ubuntu) 2.30
Regards,
Donald Dong
On Tue, Jan 1, 2019 at 9:54 AM Tom Lane wrote:
> Donald Dong writes:
> > In src/test/example, the implicit make rules produce errors:
>
> Hm. "make" in src/test/examples works fine for me.
>
> The onl
and
src/interfaces/libpq/test. There are no errors.
Thank you again for the awesome explanation,
Donald Dong
On Tue, Jan 1, 2019 at 11:54 AM Tom Lane wrote:
>
> Donald Dong writes:
> > Thank you for the explanation! That makes sense. It is strange that it does
> > not work for me.
&
I notice these patterns appear in different places. Maybe it will be better to
have a common method such as pg_str_empty()?
Regards,
Donald Dong
On Jan 9, 2019, at 4:47 PM, Michael Paquier wrote:
> That's much cleaner to me to clean up the field for safety before
> starting the process. When requesting a WAL receiver to start,
> slotname and conninfo gets zeroed before doing anything, you are right
> that we could do without it actually
r docs for testing and debugging patches more efficiently.
Now I'm having difficulties loading symbols of initdb in gdb.
Thank you,
Donald Dong
(cost=0.00..22.70 rows=1270 width=36) (actual
time=0.001..0.001 rows=0 loops=1)
I found this behavior unexpected. I'm still trying to find out how/where the
planner
determines the plan_rows. Any help will be appreciated!
Thank you,
Donald Dong
Thank you for the great explanation!
> On Jan 10, 2019, at 7:48 PM, Andrew Gierth
> wrote:
>
>>>>>> "Donald" == Donald Dong writes:
>
> Donald> Hi,
> Donald> I created some empty tables and run ` EXPLAIN ANALYZE` on
> Donald> `
> On Jan 10, 2019, at 8:01 PM, Tom Lane wrote:
>
> ... estimate_rel_size() in plancat.c is where to look to find out
> about the planner's default estimates when it's lacking hard data.
Thank you! Now I see how the planner uses the rows to estimate the cost and
generates the best_plan.
To me,
> On Jan 11, 2019, at 9:14 AM, Peter Eisentraut
> wrote:
>
>> The patch cannot be applied directly on HEAD. So I patched it on top of
>> 60d99797bf.
>
> Here is an updated patch with the merge conflicts of my own design
> resolved. No functionality changes.
>
>> When I call pg_log_error()
> On Jan 11, 2019, at 10:40 AM, Andres Freund wrote:
>
> And of course it'd change the dump's text contents between ryu and
> non-ryu backends even with extra_float_digits = 3, but the resulting
> floats ought to be the same. It's just that ryu is better at figuring
> out what the minimal text
> On Jan 15, 2019, at 2:37 AM, Andrew Gierth
> wrote:
>
> Andres> strtod()'s job ought to computationally be significantly easier
> Andres> than the other way round, no? And if there's buggy strtod()
> Andres> implementations out there, why would they be guaranteed to do
> Andres> the correct t
34 matches
Mail list logo
