Hi,
Can we also check if the clang's version is compatible with llvm's version
in llvm.m4? I have multiple llvm toolchains installed on my system and I
have to specify the $CLANG and $LLVM_CONFIG variables each time I build the
server against a toolchain that is not present in $PATH. If one of
Attached is the v10 patch. This version enhances the performance of
pattern matching. Previously it generated all possible pattern string
candidates. This resulted in unnecessarily large number of
candidates. For example if you have 2 pattern variables and the target
frame includes 100 rows, the
Rebased. I also noticed this woefully out of date line:
- PGAC_PATH_PROGS(LLVM_CONFIG, llvm-config llvm-config-7
llvm-config-6.0 llvm-config-5.0 llvm-config-4.0 llvm-config-3.9)
+ PGAC_PATH_PROGS(LLVM_CONFIG, llvm-config llvm-config-17
llvm-config-16 llvm-config-15 llvm-config-14)
From
On Sat, Oct 21, 2023 at 09:56:13PM -0400, Bruce Momjian wrote:
> I did some more research. It turns out that the source slot/planSlot is
> populating its pg_attribute information via makeTargetEntry() and it
> has no concept of a storage type.
>
> Digging further, I found that we cannot get rid
On Fri, Oct 20, 2023 at 09:48:05PM -0400, Bruce Momjian wrote:
> Here is the original thread from pgsql-docs:
>
>
> https://www.postgresql.org/message-id/flat/167336599095.2667301.15497893107226841625%40wrigleys.postgresql.org
>
> The report is about single-byte headers being used for
On Sat, Oct 21, 2023 at 2:45 PM Tom Lane wrote:
> Thomas Munro writes:
> > (It'd be nice if the
> > build farm logged "$LLVM_CONFIG --version" somewhere.)
>
> It's not really the buildfarm script's responsibility to do that,
> but feel free to make configure do so.
Done, copying the example of
On Sat, Oct 21, 2023 at 7:08 PM Andres Freund wrote:
> I've attached a patch revision that I spent the last couple hours working
> on. It's very very roughly based on a patch Tom Stellard had written (which I
> think a few rpm packages use). But instead of encoding details about specific
> layout
On Thu, Oct 19, 2023 at 6:16 AM Andrei Lepikhov
wrote:
> On 19/10/2023 01:50, Alexander Korotkov wrote:
> > This query took 3778.432 ms with self-join removal disabled, and
> > 3756.009 ms with self-join removal enabled. So, no measurable
> > overhead. Similar to the higher number of joins.
On Fri, Jul 21, 2023 at 12:38 PM Bharath Rupireddy
wrote:
>
> Needed a rebase. I'm attaching the v13 patch for further consideration.
Needed a rebase. I'm attaching the v14 patch. It also has the following changes:
- Ran pgindent on the new source code.
- Ran pgperltidy on the new TAP test.
-
On Fri, Oct 20, 2023 at 10:19 PM Bharath Rupireddy
wrote:
>
> On Thu, Oct 12, 2023 at 4:13 AM Andres Freund wrote:
> >
> > On 2023-10-03 16:05:32 -0700, Jeff Davis wrote:
> > > On Sat, 2023-01-14 at 12:34 -0800, Andres Freund wrote:
> > > > One benefit would be that it'd make it more realistic
Gurjeet Singh writes:
> On Fri, Oct 20, 2023 at 7:30 PM Bharath Rupireddy
> wrote:
>> There exists an extraneous break condition in
>> pg_logical_replication_slot_advance(). When the end of WAL or moveto
>> LSN is reached, the main while condition helps to exit the loop, so no
>> separate break
On Fri, Oct 20, 2023 at 7:30 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> There exists an extraneous break condition in
> pg_logical_replication_slot_advance(). When the end of WAL or moveto
> LSN is reached, the main while condition helps to exit the loop, so no
> separate break condition is needed.
Hi hackers,
EXPLAIN statement has a list of options (i.e. ANALYZE, BUFFERS,
COST,...) which help to provide useful details of query execution.
In Neon we have added PREFETCH option which shows information about page
prefetching during query execution (prefetching is more critical for Neon
Andres Freund writes:
> On October 20, 2023 11:18:19 PM PDT, Tom Lane wrote:
>> Indeed. I would have bet that Postgres on HPPA was extinct in the wild,
>> until I noticed this message a few days ago:
>>
Hi,
On October 20, 2023 11:18:19 PM PDT, Tom Lane wrote:
>Andres Freund writes:
>> It'd be one thing to continue supporting an almost-guaranteed-to-be-unused
>> platform, if we expected it to become more popular or complete enough to be
>> usable like e.g. risc-v a few years ago. But I doubt
Andres Freund writes:
> It'd be one thing to continue supporting an almost-guaranteed-to-be-unused
> platform, if we expected it to become more popular or complete enough to be
> usable like e.g. risc-v a few years ago. But I doubt we'll find anybody out
> there believing that there's a potential
Hi,
On 2023-10-19 06:20:26 +1300, Thomas Munro wrote:
> Interestingly, a new problem just showed up on the the RHEL9 s390x
> machine "lora", where a previously reported problem [1] apparently
> re-appeared. It complains about incompatible layout, previously
> blamed on mismatch between clang and
17 matches
Mail list logo
