On Tue, May 13, 2025 at 11:54 AM Andres Freund wrote:
> Hi,
>
> On 2025-05-12 23:14:59 -0400, J. Javier Maestro wrote:
> > The pgflex wrapper runs flex with an explicit environment, so it doesn't
> > inherit environment variables from the parent process. However, flex can
> > use the M4 env varia
Here is a very small comment fix, referencing the wrong function name.
There's a lot of suffixes flying around right here.
Yours,
--
Paul ~{:-)
p...@illuminatedcomputing.com
v1-0001-Fix-comment-on-SearchSysCacheLockedCopy1.patch
Description: Binary data
On Sat, May 17, 2025 at 12:38 PM Sadeq Dousti wrote:
> So, one mystery solved (no planner regression), still three questions:
> * Somewhat slower execution in PG18
I cannot recreate the problem.
The fastest plan for this query is a parallel sequential scan -- the
t_i_j_k_idx index is useless. T
Hi Michael Paquier,
> I don't quite see the value in the comment addition you are suggesting
> here: all the user-facing features related to query IDs use signed 64b
> integers, and are documented as such in the official docs. The fact
> that we store an unsigned value in the backend core cod
On Sat, May 10, 2025 at 7:08 AM Amit Kapila wrote:
>
> On Sat, May 10, 2025 at 1:05 PM Masahiko Sawada wrote:
> >
> > On Sat, May 10, 2025 at 12:00 AM Amit Kapila
> > wrote:
> > >
> > >
> > > Right, but to an extent, this is also similar to having a requirement
> > > of a logical slot on the pr
>
> thanks. I don't see regression for a normal table, at least for this test.
>
No, there isn't. I just added them as per your request ;)
In terms of your original test, I tried it out on my Ubuntu machine
and with your test as-is, I see 2.8 seconds on 17.5 and 3.3 seconds
on HEAD if the plan
>> I'll be curious about tests with a normal table as well with a
>> sufficiently large shared_buffers.
> Here are results for a normal table with default shared_buffers (128 MB) and
> large shared_buffers (4GB):
thanks. I don't see regression for a normal table, at least for this test.
In term
On 5/17/25 7:58 PM, Regina Obe wrote:
Yah that is why I was suggesting as a switch not a default option. I think the
default option works fine in most cases.
But I was thinking does pg_upgrade rely at all on OIDs? I guess that might make
this not doable. I wasn't sure if that is part of the re
> On 5/17/25 12:18 AM, Regina Obe wrote:
> > It's my understanding that right now when you run pg_upgrade it
> > creates the extension from what exists in the to be upgraded databases.
> >
> > Is there a reason why we can't have some sort of switch option that
> > allows the CREATE EXTENSION from t
>
> Yes, this is intentional as of 95dbd827f2edc
>
Thanks!
> >> > * Changing the table from TEMP to UNLOGGED makes both versions use
> >> > "Parallel Seq Scan", with PG18 being ~25% faster. (190ms vs. 150ms).
>
> I'll be curious about tests with a normal table as well with a
> sufficiently large
On 5/17/25 12:18 AM, Regina Obe wrote:
It's my understanding that right now when you run pg_upgrade it creates the
extension from what exists in the to be upgraded databases.
Is there a reason why we can't have some sort of switch option that allows
the CREATE EXTENSION from the scripts instead
On Sat, May 17, 2025 at 9:38 AM Sadeq Dousti wrote:
> So, one mystery solved (no planner regression), still three questions:
> * Somewhat slower execution in PG18
> * Planner differences in TEMP vs. UNLOGGED
> * Actual rows with decimal (1.00) vs. integer (1)
>
Regarding the last one, I believe
>> > * Also, I noticed "explain analyze" reports actual rows as a decimal
>> > number (1.00) as opposed to an integer (1); not sure if that's intentional.
Yes, this is intentional as of 95dbd827f2edc
>> > * Changing the table from TEMP to UNLOGGED makes both versions use
>> > "Parallel Seq Scan",
Hi hackers,
I will share the notes on the discussions in PGConf.dev. Thanks all for
participation.
Feedback on the Advanced Patch Feedback Session;
- A Basic idea that allows both OLTP/OLAP workloads on the same table is OK
- Buffering mechanism has already been used by existing code GIN, I
Hi,
You're right, with settings, it revealed that PG17 had random_page_cost=1.1
configured.
Adding that to PG18 sets the plan to index only; however, PG18 is still
somewhat (~15%) slower:
PG17.5 =
QUERY PLAN
Dear all,
I was testing PG18 beta 1 new features (noticeably, AIO and index skip
scan), and I came up with this example:
===
drop table if exists t;
create TEMP table t(i,j,k)
as select n,n,n
from generate_series(1,10_000_000) as n;
analyze t;
create index on t(i,j,k);
explain (analyz
The attached updated patch fixes the merge conflicts and updates the
numbering of the test files.
On Mon, Feb 24, 2025 at 12:06 PM Andrew Jackson
wrote:
> The previous patch had a mistake in a reference in the documentation. This
> should fix it.
>
> On Mon, Feb 24, 2025 at 10:07 AM Andrew Jacks
On Fri, May 16, 2025 at 04:05:01PM +0530, Shaik Mohammad Mujeeb wrote:
> This conversion is intentional - most likely to match the bigint
> type of the queryid column in pg_stat_statements. However, without
> an explicit comment, this can be misleading. A beginner reading this
> might misinterpret
18 matches
Mail list logo
