On 9/10/25 00:41, Ellen Allhatatlan wrote:
Hi, and thanks for your input,
The author brings up threaded vs multi-process. That's an old old old old old
conversation that has been shown there is no clear better way.
This is where things become interesting. Firebird actually has 3
process/th
On Tue, Sep 9, 2025 at 7:11 PM Ron Johnson wrote:
> On Tue, Sep 9, 2025 at 8:41 PM Justin wrote:
>
>>
>> On autonomous transactions we have procedures now that allow transactions
>> inside of transactions that can be committed and rollbacked. that has been
>> around for several years now.
>>
>
On 9/10/25 08:11, Ron Johnson wrote:
On Wed, Sep 10, 2025 at 11:08 AM Ellen Allhatatlan
mailto:[email protected]>> wrote:
[snip]
So, you have table X - it has 2M rows (say, 0.5 GB) in the first file
(along with all the other tables). The 2GB limit is hit, more data is
added
On Thu, Sep 11, 2025 at 5:38 AM Ellen Allhatatlan <
[email protected]> wrote:
> "A last aspect of our design concerns the operating system process
> structure. Currently, POSTGRES runs as one process for each active
> user. This was done as an expedient to get a system operational as
> qu
On Wed, Sep 10, 2025 at 11:08 AM Ellen Allhatatlan <
[email protected]> wrote:
[snip]
> So, you have table X - it has 2M rows (say, 0.5 GB) in the first file
> (along with all the other tables). The 2GB limit is hit, more data is
> added. 0.7 GB is added to table X - these records go into
> > In part 1. Differences in MVCC implementation - he's saying that "It’s
> > not that the PostgreSQL implementation of MVCC is bad — it’s just
> > fundamentally different"
> It is written by someone @firebirdsql.org so one assumes a few grains of salt
> necessary.
I know - but the guy does st
On Fri, Sep 12, 2025 at 3:18 PM Ellen Allhatatlan <
[email protected]> wrote:
> You, (Merlin Moncure) said:
>
> > Technical discussions from the 80's are more or less historically
> interesting only.
>
> I agree with your technical points - and the fact that I brought up
> "history".
>
>
You, (Merlin Moncure) said:
> Technical discussions from the 80's are more or less historically interesting
> only.
I agree with your technical points - and the fact that I brought up "history".
I was replying to Justin in this context:
I wrote:
> AIUI, Michael Stonebraker suggested that the
> On Sep 9, 2025, at 10:27 AM, Ellen Allhatatlan
> wrote:
>
> Reading this article
> https://firebirdsql.org/migrating-from-firebird-to-postgresql-what-can-go-wrong-
> I'm a bit confused (not the first time...)
>
> In part 1. Differences in MVCC implementation - he's saying that "It’s
> not
Hi
> Final thoughts on this: firebird (fmrly interbase) did not achieve the
> level of success in the market that postgres, even though they may have
> been similarly positioned. My take: that disparity in success has more to
> do with postgres having a more open development model, stronger comm
>> AIUI, Michael Stonebraker suggested that the process model
>> would/should be "upgraded" to a threaded one at some point in the
>> system's developement?
> I am going to need a source on this. Process vs Threads: pro and cons are
> very well documented and proven today.
Ask, and it will be
On Tue, Sep 09, 2025 at 08:41:02PM -0400, Justin wrote:
> The author brings up threaded vs multi-process. That's an old old old old
> old conversation that has been shown there is no clear better way.
This is relevant to the next part:
> Number of open connections. so firebird can do 1000 open
On Wed, Sep 10, 2025 at 6:20 PM Justin wrote:
> On Wed, Sep 10, 2025 at 5:28 PM Nico Williams
> wrote:
>
>> [snip]
> I would really like out-of-band hints. These would be hints not
>> specified in the SQL itself but to be sent separately and which address
>> table sources or joins by name, li
On Wed, Sep 10, 2025 at 06:20:18PM -0400, Justin wrote:
> I am not following you here, Databases are going to be bound somewhere at
> some point, Disk,IO, Network IO, Memory, or CPU bound. Which one is
> causing the bottle neck just depends on the workload and size of the
> database.
>
> The nu
On Wed, Sep 10, 2025 at 5:28 PM Nico Williams wrote:
> On Tue, Sep 09, 2025 at 08:41:02PM -0400, Justin wrote:
> > The author brings up threaded vs multi-process. That's an old old old old
> > old conversation that has been shown there is no clear better way.
>
> This is relevant to the next part
On Tue, Sep 9, 2025 at 8:41 PM Justin wrote:
[snip]
> Multiple transactions per connection. I am asking WHY is that a feature.
> when one can have multiple sessions, what is the difference? running
> multiple transactions in single or multiple sessions means moving part of
> transaction logic
On 2025-Sep-10, Justin wrote:
> On Wed, Sep 10, 2025 at 3:41 AM Ellen Allhatatlan <
> [email protected]> wrote:
> > > The author brings up threaded vs multi-process. That's an old old old
> > old old conversation that has been shown there is no clear better way.
> >
> > This is where thi
On Wed, Sep 10, 2025 at 3:41 AM Ellen Allhatatlan <
[email protected]> wrote:
> Hi, and thanks for your input,
>
> Just before I reply - if you (at least here in Ireland - Google's
> answers vary per location, unlike Duckduckgo's) search for "firebird
> mvcc mechanism" the "AI assistant"
> Though I would like to know what happened in mid 2010?:
> https://github.com/FirebirdSQL/firebird/graphs/contributors
Yes, indeed, WTF? I'm not a member of the FB Illuminati - so I can't say!
> > OK again. I'm just wondering if the single file per database isn't a
> > fundamental architectural
Hi, and thanks for your input,
Just before I reply - if you (at least here in Ireland - Google's
answers vary per location, unlike Duckduckgo's) search for "firebird
mvcc mechanism" the "AI assistant" tells me twice that FB's MVCC
implementation is "like PostgreSQL's"... I'll investigate further a
On Tue, Sep 9, 2025 at 9:12 PM Ron Johnson wrote:
> On Tue, Sep 9, 2025 at 8:41 PM Justin wrote:
>
>>
>> XID being 32 bit
>>
>
> Would converting them to 64 bits require changing the on-disk structure of
> database files?
>
Yes this is one of the reasons 64 bit xid has not be used yet. pg_upgr
On Tue, Sep 9, 2025 at 8:41 PM Justin wrote:
> I read through the article its click bait/flame war just waiting to happen.
>
> Article is a list of cherry picked PG drawbacks that can be mitigated or
> worked around.
>
> On the bulk updating. I'm shaking my finger at any one that locks up 25%
>
On Tue, Sep 9, 2025 at 10:27 AM Ellen Allhatatlan <
[email protected]> wrote:
> Reading this article
>
> https://firebirdsql.org/migrating-from-firebird-to-postgresql-what-can-go-wrong-
> I'm a bit confused (not the first time...)
>
> In part 1. Differences in MVCC implementation - he's s
I read through the article its click bait/flame war just waiting to happen.
Article is a list of cherry picked PG drawbacks that can be mitigated or
worked around.
On the bulk updating. I'm shaking my finger at any one that locks up 25%
of a table with an update or delete. That is asking for pro
On Tue, Sep 9, 2025 at 11:57 AM Ellen Allhatatlan <
[email protected]> wrote:
> > Note: your link is wrong, corrected here:
>
> Extra hyphen - sorry about and thanks for pointing it out!
>
> > What the article is driving at is that postgres does not use rollback
> logs to handle updated r
> Note: your link is wrong, corrected here:
Extra hyphen - sorry about and thanks for pointing it out!
> What the article is driving at is that postgres does not use rollback logs to
> handle updated records in the MVCC implementation. There are absolutely
> performance tradeoffs in that decis
26 matches
Mail list logo
