On Fri, Sep 20, 2024 at 4:27 PM Marcos Pegoraro wrote:
> Em sex., 20 de set. de 2024 às 15:11, Tomas Vondra
> escreveu:
>
>> IMHO it's quite reasonable to say "we do X, but this other product
>> (which is what we try to mimic) does Y".
>>
>
> Ok, for Data Type Formatting Functions is fine, if th
s well. While these
things do reduce CPU, there are a number of negative aspects to deal with
that make such an architecture more difficult to manage.
--
Jonah H. Harris
d check out Citus' original cstore implemented via FDW. It
hasn't been updated in years, but it's still one of the faster simple
columnar implementations out there https://github.com/citusdata/cstore_fdw
--
Jonah H. Harris
Pinging to see if anyone has continued to work on this behind-the-scenes or
whether this is the latest patch set there is.
--
Jonah H. Harris
s for anyone who wants to do their own custom parser. See Julien
Rouhaud's SQLOL in the "Hook for extensible parsing" thread and Jim
Mlodgenski's "Parser Hook" thread.
--
Jonah H. Harris
s, but it would
also increase the learning curve for anyone trying to start with internals
development.
--
Jonah H. Harris
ion makes no sense. If you want to understand how things actually
work, you need to read the code in context and understand how the system
works, minimally, at a component level.
--
Jonah H. Harris
On Fri, Feb 17, 2023 at 12:03 AM David Rowley wrote:
> On Fri, 17 Feb 2023 at 17:40, Jonah H. Harris
> wrote:
> > Yeah. There’s definitely a smarter and more reusable approach than I was
> proposing. A lot of that code is fairly mature and I figured more people
> wouldn’t w
some context that only wants
> a 1KB initial block.
Yeah. There’s definitely a smarter and more reusable approach than I was
proposing. A lot of that code is fairly mature and I figured more people
wouldn’t want to alter it in such ways - but I’m up for it if an approach
like this is the direction we’d want to go in.
--
Jonah H. Harris
alternate allocation strategy, I don’t know
how it would be very clean API-wise, but it’s definitely an idea.
--
Jonah H. Harris
27;t encountering this scenario.
I have a patch to make it configurable, but before submitting it, I wanted
to hear your thoughts and feedback on this and any other alternative ideas
you may have.
--
Jonah H. Harris
acks, but perhaps we'd ensure that
> they're both set.
>
This is a bad example as it doesn't require semantic analysis from
Postgres. While most of the tools out there tend to do simple replacement,
this can be done within a custom parser by simply walking its own AST,
evaluating join conditions against the expression, and rewriting the join
accordingly. Or, do you have an example that couldn't be done this way
within a custom parser?
--
Jonah H. Harris
l B-Tree. Similarly, where most academic
research starts to fall apart in practicality is the lack of addressing
realistic write volumes and related concurrency issues. I'm happy to be
disproven on this, though.
--
Jonah H. Harris
ity... as is anything loaded directly into the process.
--
Jonah H. Harris
ot possible
> with the approach taken here. Not sure about the others things you listed.
>
Accessing multiple databases from the same backend is problematic overall -
I didn't solve that in my implementations either. IIRC, once a bgworker is
attached to a specific database, it's basically stuck with that database.
--
Jonah H. Harris
his last email, they're not proposing all the different
aspects needed. In fact, nothing has actually been proposed yet. This is an
entirely philosophical debate. I don't even know what's being proposed at
this point - I just know it *could* be useful. Let's just wait and see what
is actually proposed before shooting it down, yes?
--
Jonah H. Harris
his vs. posited about its
usefulness, I'd say it has some merit and doesn't really introduce that
much complexity or maintenance overhead to core - whether the extensions
still work properly is up to the extension authors... isn't that the whole
point of extensions?
--
Jonah H. Harris
; So maybe we should just not bother with the first step either.
>
Perhaps I'm misunderstanding you, but I wouldn't throw this entire idea out
(which enables a substantial addition of extensible functionality with a
limited set of touchpoints) on the premise of future objections.
--
Jonah H. Harris
for my
Oracle-compatible stuff, I don't think I'd be able to do anything other
than the protocol as an extension given the core-related changes similar to
what EDB has to do. I don't think there's any easy way to get around that.
But, for the protocol and any type of simple translation to Postgres'
dialect, I think that could easily be hook-based.
--
Jonah H. Harris
would be great to have a standard, loadable, way to add support for a new
protocol.
--
Jonah H. Harris
On Fri, Jul 3, 2020 at 3:20 PM Pavel Stehule
wrote:
> Hi
>
> I am sorry, wrong mailing list.
>
Thanks for reading/sharing my blog post, regardless of the mailing list :)
--
Jonah H. Harris
ould be done without
reading the functionality to core (which would be new functionality given
all the changes.) I’d say start with the extensions and go from there.
--
Jonah H. Harris
On Sat, Jun 27, 2020 at 3:37 PM Christoph Berg wrote:
> Re: Jonah H. Harris
> > Somewhere, I recall seeing an open-source OpenSSL compatibility wrapper
> for
> > WolfSSL. Assuming that still exists, this patch seems entirely
> unnecessary.
>
> Unless you actually trie
an open-source OpenSSL compatibility wrapper for
WolfSSL. Assuming that still exists, this patch seems entirely unnecessary.
--
Jonah H. Harris
shorten one or two of the very longest
> names, because they're just giving me fits in fixing the PDF
> rendering. (They would make a mess of the display of
> pg_stat_activity, too, anytime they come up in the field.)
>
> Thoughts?
>
+1
--
Jonah H. Harris
On Fri, May 1, 2020 at 4:59 PM Thomas Munro wrote:
> On Fri, May 1, 2020 at 12:28 PM Jonah H. Harris
> wrote:
> > Also, this will likely have an issue with O_DIRECT as additional buffer
> manager alignment is needed and I haven't tracked it down in 13 yet. As my
> defa
On Wed, Apr 29, 2020 at 8:34 PM Jonah H. Harris
wrote:
> On Tue, Apr 28, 2020 at 8:10 AM Andreas Karlsson
> wrote:
>
>> To get the performance benefits from using raw devices I think you would
>> want to add support for asynchronous IO to PostgreSQL rather than
>> imp
ting a
2Q variant) but that wasn't public. I had also prototyped raw device
support, which is a good amount of work and required implementing a custom
filesystem (similar to Oracle's ASM) within the storage manager. It's
probably a bit harder now than it was then, given the number of different
types of file access.
--
Jonah H. Harris
On Wed, Apr 29, 2020 at 5:54 PM Jonah H. Harris
wrote:
> On Wed, Apr 29, 2020 at 4:50 PM Corey Huinker
> wrote:
>
>> Having both WHERE and WHILE might look awkward.
>>>
>>
>> Maybe an UNTIL instead of WHILE?
>>
>
> While I'm not a huge fan
H ITERATIVE R AS '(' R0 ITERATE Ri UNTIL N (ITERATIONS | UPDATES) ')' Qf
Where N in ITERATIONS represents termination at an explicit count and, in
UPDATES, represents termination after Ri updates more than n rows on table
R.
--
Jonah H. Harris
L
> SELECT recursive case
> )
>
I was originally thinking more along the lines of Fabien's approach, but
this is similarly interesting.
--
Jonah H. Harris
.00..0.01 rows=1 width=68) (actual
time=0.001..0.001 rows=1 loops=1)
-> WorkTable Scan on fib_sum (cost=0.00..0.24 rows=3 width=68)
(actual time=0.001..0.001 rows=1 loops=10001)
Filter: (iteration <= 1)
Rows Removed by Filter: 0
Planning
nasty, we could always similarly amend WITH RECURSIVE to
add an additional ITERATE or something to the tail of the with_clause rule.
But, that's why I'm looking for feedback :)
We do have someone on the committee who watches these lists, hopefully
> they'll have a chance to comment on this. Perhaps it's already in
> discussion in the committee.
>
That would be awesome.
--
Jonah H. Harris
o
carry the counters along in the executor itself. But, as not all uses of
this functionality are iteration-count-based, I think that's a little
limiting. Using a terminator expression (of some kind) seems most
adaptable, I think. I'll give some examples of both types of cases.
--
Jonah H. Harris
c research on it, if you're interested, here's
a few papers with examples:
http://faculty.neu.edu.cn/cc/zhangyf/papers/2018-ICDCS2018-sqloop.pdf
http://db.in.tum.de/~passing/publications/dm_in_hyper.pdf
--
Jonah H. Harris
On Tue, Apr 28, 2020 at 6:16 AM Oleksandr Shulgin <
oleksandr.shul...@zalando.de> wrote:
> will help the community to focus on the actual details of your proposal.
>
I'd like it if the community would focus on the details of the proposal as
well :)
--
Jonah H. Harris
as seeing
feedback. Honestly, David, stop wasting my, and list time, asking pointless
off-topic questions.
--
Jonah H. Harris
On Mon, Apr 27, 2020 at 10:32 PM David Fetter wrote:
> On Mon, Apr 27, 2020 at 12:52:48PM -0400, Jonah H. Harris wrote:
> > Hey, everyone.
>
> > If there's any interest, I'll clean-up their patch and submit. Thoughts?
>
> Where's the current patch?
It’s
lean-up their patch and submit. Thoughts?
--
Jonah H. Harris
e there are who actually *like* colored output?
> I find it to be invariably less readable than plain B&W text.
>
Same.
> I may well be in the minority, but I think some kind of straw poll
> might be advisable, rather than doing this just because.
>
+1 on no color by default.
--
Jonah H. Harris
; What do you think about this crazy idea?
>
> > Turning "IS NOT DISTINCT FROM" into an operator sounds like a great
> > idea.
>
> No it isn't.
+1
--
Jonah H. Harris
on because pgbench was too
different. pgbench itself isn't that useful as a benchmark tool, imo, but
if we have the ability to make it better (i.e. closer to an actual
benchmark kit), I think we should.
--
Jonah H. Harris
> Can you improve indexing by this?
>
> Understandably
>
> Sascha Kuhl
>
--
Jonah H. Harris
On Fri, Dec 14, 2018 at 12:28 AM Pavel Stehule
wrote:
>
>
> čt 13. 12. 2018 v 10:23 odesílatel Simon Riggs
> napsal:
>
>> Thoughts?
>>
>
> looks great
>
Agreed. This sounds well-thought-out and rather simple to implement.
--
Jonah H. Harris
Ahh. Gotcha. Makes sense.
On Thu, Dec 6, 2018 at 11:57 AM Robert Haas wrote:
> On Thu, Dec 6, 2018 at 11:39 AM Jonah H. Harris
> wrote:
> > IIRC, PRAGMA in Ada was compile-time only. How would you foresee it
> affecting runtime?
>
> Well, I don't know what Ada doe
x27;t see a big problem allowing some kind of annotation that
> plpgsql_check can easily access, and I don't even mind it being called
> PRAGMA. But I don't think it should foreclose unrelated uses of
> PRAGMA which somebody might want to introduce in the future.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> --
Jonah H. Harris
but it is expected, there is nothing like query string for
> plpgsql statement.
>
> Regards
>
> Pavel
>
>> -----
>> Pavel Luzanov
>> Postgres Professional: http://www.postgrespro.com
>> The Russian Postgres Company
>>
>>
>> --
Jonah H. Harris
e warning message was inappropriate and
> overcomplicated, so I just dropped it. I don't think we really need
> anything there.
>
+1
--
Jonah H. Harris
t scenarios in which either choice could be
> argued to break something; but I think the most likely avenue for
> trouble is if the visible setting doesn't match the actual behavior.
> So I'm leaning to the assign-hook approach; comments?
>
My patch used the check hook, but works either way.
--
Jonah H. Harris
On Tue, Nov 6, 2018 at 2:46 PM Isaac Morland
wrote:
> On Tue, 6 Nov 2018 at 14:07, Jonah H. Harris
> wrote:
>
>> Two options presented:
>>
>> - Hard patch removes FATAL/PANIC from client_message_level_options in
>> guc.c, which also seems to make sense in re
ERROR when set to FATAL/PANIC and issues a warning.
This also exports error_severity from elog.c to retrieve severity -> text
mappings for the warning message.
--
Jonah H. Harris
client_min_messages_config_hard.patch
Description: Binary data
client_min_messages_config_soft.patch
Description
51 matches
Mail list logo
