> On Jun 17, 2024, at 5:35 AM, Julius Tuskenis
> wrote:
>
>
> Isn't PosgreSQL supposed to inline simple SQL functions that are stable or
> immutable?
Postgres inlines SQL functions under certain conditions:
https://wiki.postgresql.org/wiki/Inlining_of_SQL_functions
One of those conditions
> On Jan 30, 2024, at 4:40 AM, Pavlos Kallis wrote:
>
> Shouldn't VACUUM ANALYZE reclaim the disk space?
Hi Pavlos,
The short answer to this is “no”. That’s an important difference between VACUUM
(also known as “plain” VACUUM) and VACUUM FULL. In some special cases plain
VACUUM can reclaim
> On Nov 8, 2023, at 8:26 PM, Lincoln Swaine-Moore
> wrote:
>
> Hi all--
>
> I'm having a performance problem in 12.16 that I'm hoping someone can help
> with.
> Thanks for any and all help and suggestions.
Hi Lincoln,
I haven't read your SQL carefully so I may be completely off base,
Hi there,
I’m on Postgres 13.11 and I'm seeing a situation where an INSERT...SELECT
statement seq scans an index, but only when wrapped in a SQL function. When
invoked directly (via psql) or when called via a PL/pgSQL function, it only
reads the index tuples it needs, resulting in much better pe
p
>
> Em qui., 25 de fev. de 2021 às 17:53, Philip Semanchuk
> escreveu:
>
>
> > On Feb 25, 2021, at 3:46 PM, Igor Gois wrote:
> >
> > Hi, Philip
> >
> > We ran: EXPLAIN (FORMAT JSON) SELECT "Id", "DateTime", "SignalReg
(calculated in python client)
>
> https://explain.depesz.com/s/5HRO
>
> Thanks in advance
>
>
> Em qui., 25 de fev. de 2021 às 15:13, Philip Semanchuk
> escreveu:
>
>
> > On Feb 24, 2021, at 10:11 AM, Igor Gois wrote:
> >
> > Hi, Julien
> &g
> On Feb 24, 2021, at 10:11 AM, Igor Gois wrote:
>
> Hi, Julien
>
> Your hypothesis about network transfer makes sense. The query returns a big
> size byte array blobs.
>
> Is there a way to test the network speed against the instances? I have access
> to the network speed in gcp (5 Mb/s),
> On Nov 2, 2020, at 10:17 PM, Tomas Vondra
> wrote:
>
> On Mon, Nov 02, 2020 at 03:08:12PM -0500, Tom Lane wrote:
>> Philip Semanchuk writes:
>>> The query I asked about in the original post of this thread has 13
>>> relations in it. IIUC, that's 1
> On Nov 2, 2020, at 6:09 PM, Michael Lewis wrote:
>
> The query I asked about in the original post of this thread has 13 relations
> in it. IIUC, that's 13! or > 6 billion possible plans. How did the planner
> pick one plan out of 6 billion? I'm curious, both for practical purposes (I
> wa
> On Oct 31, 2020, at 9:53 AM, Guillaume Lelarge wrote:
>
> Hi,
>
> Le ven. 30 oct. 2020 à 15:57, Philip Semanchuk
> a écrit :
>
>
> > On Oct 29, 2020, at 6:48 PM, Tomas Vondra
> > wrote:
> >
> > On Thu, Oct 29, 2020 at 11:25:48AM -04
> On Oct 29, 2020, at 6:48 PM, Tomas Vondra
> wrote:
>
> On Thu, Oct 29, 2020 at 11:25:48AM -0400, Philip Semanchuk wrote:
>>
>>
>>> On Oct 28, 2020, at 9:13 PM, Justin Pryzby
>>> wrote:
>>>
>>> On Mon, Oct 26, 2020 at 11:20:0
> On Oct 28, 2020, at 9:13 PM, Justin Pryzby wrote:
>
> On Mon, Oct 26, 2020 at 11:20:01AM -0600, Michael Lewis wrote:
>> On Mon, Oct 26, 2020 at 11:14 AM Philip Semanchuk
>> wrote:
>>
>>>>> The item I'm focused on is node 23. The estimate
> On Oct 26, 2020, at 1:20 PM, Michael Lewis wrote:
>
> On Mon, Oct 26, 2020 at 11:14 AM Philip Semanchuk
> wrote:
> >> The item I'm focused on is node 23. The estimate is for 7 rows, actual is
> >> 896 (multiplied by 1062 loops). I'm confused about
> On Oct 26, 2020, at 1:04 PM, Justin Pryzby wrote:
>
> On Mon, Oct 26, 2020 at 12:50:38PM -0400, Philip Semanchuk wrote:
>> I'm trying to understand a bad estimate by the planner, and what I can do
>> about it. The anonymized plan is here: https://explain.d
I'm trying to understand a bad estimate by the planner, and what I can do about
it. The anonymized plan is here: https://explain.depesz.com/s/0MDz
The item I'm focused on is node 23. The estimate is for 7 rows, actual is 896
(multiplied by 1062 loops). I'm confused about two things in this node.
> On Jun 4, 2020, at 3:03 PM, Sebastian Dressler wrote:
>
> Hi Philip,
>
>> On 4. Jun 2020, at 20:37, Philip Semanchuk
>> wrote:
>>
>> [...]
>>>
>>>> This brings up a couple of questions —
>>>> 1) I’ve read that this
> On Jun 4, 2020, at 1:45 PM, Sebastian Dressler wrote:
>
> Hi Philip,
>
>> On 4. Jun 2020, at 18:41, Philip Semanchuk
>> wrote:
>> [...]
>>
>>> Also, there are more configuration settings related to parallel queries y
> On Jun 4, 2020, at 2:28 AM, Sebastian Dressler wrote:
>
> Hi Philip,
>
>> On 4. Jun 2020, at 00:23, Philip Semanchuk
>> wrote:
>>
>>> I guess you should show an explain analyze, specifically "Workers
>>> Planned/Launched"
> On Jun 3, 2020, at 5:15 PM, Justin Pryzby wrote:
>
> On Wed, Jun 03, 2020 at 04:04:13PM -0400, Philip Semanchuk wrote:
>> Can anyone help me understand why this happens, or where I might look for
>> clues?
>
> What version postgres ?
Sorry, I should have post
Hi all,
I’ve been experimenting with some performance tuning on a particular query, and
I observed a result that I don’t understand.
I’ve been setting max_parallel_workers_per_gather to values the range 1-6 and
then running EXPLAIN ANALYZE to see how much benefit we get from more
parallelizat
20 matches
Mail list logo
