sey
and others; working to polish anything else that might be required of us.
Todd
On Wed, 2 Feb 2022 at 10:56, Todd Hubers wrote:
> Hi Everyone,
>
> Benchmarking work has commenced, and is ongoing.
>
>- *OPTIONS 5/6/7* - `SET SESSION AUTHORIZATION` takes double the time
&g
Impersonation
message might have a flag (valid for 1x SimpleQuery only, then
automatically restore back to the last user).
Regards,
Todd
On Fri, 7 Jan 2022 at 10:55, Todd Hubers wrote:
> Hi Everyone,
>
> I have started working on this:
>
>- Benchmarking - increasingly mor
to add support (when the
GRANT role privilege is available))
I hope to have a patch ready by the end of March.
Regards,
Todd
On Wed, 24 Nov 2021 at 02:46, Todd Hubers wrote:
>
> Hi Jacob and Daniel,
>
> Thanks for your feedback.
>
> >@Daniel - I think thats confla
that, for sure.
>
> Having protocol-level tests for bytes on the wire would not only help
> proposals like this but also get coverage for a huge number of edge
> cases. Magnus has added src/test/protocol for the server, written in
> Perl, in his PROXY proposal. And I've added a protocol suite for both
> the client and server, written in Python/pytest, in my OAuth proof of
> concept. I think something is badly needed in this area.
>
> --Jacob
>
--
--
Todd Hubers
(timestamp), so we won't need to rewind the right table, only to
> > advance it forward.
> >
> > Given the sorted input paths, this algorithm is linear time in size of
> > the tables. A drawback of this algorithm is that it requires memory
> > proportional to the cardinality of the equi-columns. A possible
> > optimization is to split the equi-key hash table into hot and cold
> > parts by LRU, and dump the cold part to disk. This would help if each
> > equi-key only occurs for a small period of time.
> >
> >
> > 4. Nested Loop
> >
> > An efficient nested loop plan has to have a fast right-side subplan,
> > such as an index lookup. Unfortunately, there seems to be no way to
> > efficiently perform a last-point lookup for given equi-keys, if we
> > have separate btree indexes on timestamp and equi-keys. The nested
> > loop plan could work if we have a (timestamp, equi-keys) btree index.
> >
> >
> > Prototype Implementation
> >
> > For a prototype, I'd go with #3 "merge-something with a hash table of
> > most recent rows for equi-keys", because it works for big tables and
> > can reuse the physical data ordering.
> >
> >
> > I'll be glad to hear your thoughts on this.
> >
> >
> > --
> > Alexander Kuzmenkov
> > Timescale
> >
>
>
>
--
--
Todd Hubers
aspect.
*13. Tom said:* "I wonder how we test such a feature meaningfully *without
incorporating a pooler right into the Postgres tree*."
*We can benchmark without a pooler* - see the Benchmark section for details
*.* (Furthermore, I propose that general benchmark tooling does belong in
Pos
https://docs.google.com/document/d/1u6mVKEHfKtR80UrMLNYrp5D6cCSW1_arcTaZ9HcAKlw/edit?usp=sharing.
Feel free to request Edit access.
- The current PDF version is attached too for archive purposes
I am very keen to make this happen.
Thanks
--
--
Todd Hubers
PostgreSQL Change User
