ll. 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
t 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
ne 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
the learning curve for anyone trying to start with internals
development.
--
Jonah H. Harris
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
> woul
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
rnate allocation strategy, I don’t know
how it would be very clean API-wise, but it’s definitely an idea.
--
Jonah H. Harris
ng 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
t;
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
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
ty... as is anything loaded directly into the process.
--
Jonah H. Harris
h 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
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
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
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
ng 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
It
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
ource OpenSSL compatibility wrapper for
WolfSSL. Assuming that still exists, this patch seems entirely unnecessary.
--
Jonah H. Harris
n 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
> d
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
>>
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 fa
RATIVE 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
SELECT recursive case
> )
>
I was originally thinking more along the lines of Fabien's approach, but
this is similarly interesting.
--
Jonah H. Harris
) (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 Time: 0.068 ms
Executio
URSIVE 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
ecutor 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
t, 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 private.
. Thoughts?
--
Jonah H. Harris
e there are who actually *like* colored output?
> I find it to be invariably less readable than plain B 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
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
o
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
lem 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
t 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
t the warning message was inappropriate and
> overcomplicated, so I just dropped it. I don't think we really need
> anything there.
>
+1
--
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 sen
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: Bin
49 matches
Mail list logo
