## GPT (gptmailingli...@gmail.com):
> Why this incident has been observed when the statement is only within
> a function with variable as input parameter and not when they run
> directly with explicitly defined parameter/ In the first case, plan
> remains stable and does not change; but in the sec
## GPT (gptmailingli...@gmail.com):
> > And the important thing is: there is no guarantee that the same SQL
> > statement will always execute with the same plan:
> + Yes but there should be guarantee that when the statement is free of
> any syntactic error to be executed successfully and return th
> On 27 Oct 2018, at 18:14, David G. Johnston
> wrote:
>
>> On Saturday, October 27, 2018, joernbs wrote:
>> Dear friends,
>>
>> I would like to use ltree for search paths in a warehouse application,
>> something like "Material-Entry-01.Main-Aisle.Shelf-Aisle-R07/R08.R07-12-03"
>> Unfortuna
On 10/27/18 8:00 AM, GPT wrote:
On 10/27/18, Adrian Klaver wrote:
On 10/27/18 2:28 AM, GPT wrote:
...
Postgres is going to do all sorts of things under the hood when you run
a query, that is not going to change.
+ Ok. That's clear.
+
The issue you had bubbled up to
you the user because the FD
On Saturday, October 27, 2018, joernbs wrote:
> Dear friends,
>
> I would like to use ltree for search paths in a warehouse application,
> something like "Material-Entry-01.Main-Aisle.
> Shelf-Aisle-R07/R08.R07-12-03"
> Unfortunately I can not use common separators like dash (-) or slash(/)
>
> D
Dear friends,
I would like to use ltree for search paths in a warehouse application,
something like "Material-Entry-01.Main-Aisle.Shelf-Aisle-R07/R08.R07-12-03"
Unfortunately I can not use common separators like dash (-) or slash(/)
Documentation states only thes characters [A-Za-z0-9_] are allow
On 10/27/18, Adrian Klaver wrote:
> On 10/27/18 2:28 AM, GPT wrote:
> ...
> Postgres is going to do all sorts of things under the hood when you run
> a query, that is not going to change.
+ Ok. That's clear.
+
> The issue you had bubbled up to
> you the user because the FDW you where using got cau
On 10/27/18 3:57 AM, GPT wrote:
And one more question:
Anyway, this is too technical for me and even if you respond most
probably I am not gonna get it.
Then why ask the question?
Tia
--
Adrian Klaver
adrian.kla...@aklaver.com
On 10/27/18 2:28 AM, GPT wrote:
On 10/26/18, Christoph Moench-Tegeder wrote:
## GPT (gptmailingli...@gmail.com):
...
And the important thing is: there is no guarantee that the same SQL
statement will always execute with the same plan:
+ Yes but there should be guarantee that when the stateme
see
https://www.postgresql.org/docs/9.5/static/app-psql.html
for psql options an commands:
psql -d ... -U ...
\d+ measurement_year_month
...
Partition key: RANGE (date_part('year'::text, logdate),
date_part('month'::text, logdate))
Number of partitions: 0
if you want to know how postgresql is r
And one more question:
Why this incident has been observed when the statement is only within
a function with variable as input parameter and not when they run
directly with explicitly defined parameter/ In the first case, plan
remains stable and does not change; but in the second case plan
changes
On 10/26/18, Christoph Moench-Tegeder wrote:
> ## GPT (gptmailingli...@gmail.com):
>
>...
>
> And the important thing is: there is no guarantee that the same SQL
> statement will always execute with the same plan:
+ Yes but there should be guarantee that when the statement is free of
any syntactic
12 matches
Mail list logo
