Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the placement of BLOBs in same page with data or on separate page configurable [CORE2056] #2492

Open
firebird-automations opened this issue Aug 28, 2008 · 8 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Smirnoff Serg (wildsery)

Votes: 2

Firebird core decide to keep BLOB on same page or on separate page for the only reason of the size of BLOB, omit the programmer's opinion on that issue.
In sertain conditions (for ex. "million-record" tables with small-size BLOBs) there's necessarity to keep BLOB fields apart from data for faster data access.
I consider that this action will take much more data pages, but I insist that in some cases faster data access in price of storage consumption is acceptable.

@firebird-automations
Copy link
Collaborator Author

Modified by: Smirnoff Serg (wildsery)

summary: Make the placement of BLOBs in same page witn data or on separate page configurable => Make the placement of BLOBs in same page with data or on separate page configurable

@firebird-automations
Copy link
Collaborator Author

Modified by: Smirnoff Serg (wildsery)

description: Firebird core decide to keep BLOB on same page or on separate page for the only reason of the size of BLOB, omit the programmer's opinion on that issue.
In sertain conditions (for ex. "million-record" tables with small-size BLOBs) there's necessarity to keep BLOB fields apart from data for faster data access.
I consider that this action will take much more data pages, but I insist that in some cases faster data access in price of storage place consumption is acceptable.

=>

Firebird core decide to keep BLOB on same page or on separate page for the only reason of the size of BLOB, omit the programmer's opinion on that issue.
In sertain conditions (for ex. "million-record" tables with small-size BLOBs) there's necessarity to keep BLOB fields apart from data for faster data access.
I consider that this action will take much more data pages, but I insist that in some cases faster data access in price of storage consumption is acceptable.

@firebird-automations
Copy link
Collaborator Author

Commented by: Nikolay Ponomarenko (pnv82)

But you can make separate table for those blobs...

@firebird-automations
Copy link
Collaborator Author

Commented by: Smirnoff Serg (wildsery)

Yep. And TWO multimegabyte indices for control 1:1 referential integrity (see CORE651 for details). As addition for other excess actions...

@firebird-automations
Copy link
Collaborator Author

Commented by: Michiel Spoor (mdspoor)

As I understand things, NOT having BLOB's on the same page as the regular datafields could significantly improve performance of queries.
If this could be done by adjusting the BLOB field definition, this improvement could come at a much more easy way for us developers than having to split the BLOB into a separate table, with all the hassle of
- converting an existing application
- managing two tables
- performance loss in storing/retrieving the blobs because of the extra PK/FK indices on the second table.

As I see it, it could be a *very* interesting feature, at a possibly very small cost.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Michiel,

> As I understand things, NOT having BLOB's on the same page as the regular datafields
> could significantly improve performance of queries

True, but only fot the queries that don't read blobs. And it will decrease performance of the queries that read blobs along with other fields.

@firebird-automations
Copy link
Collaborator Author

Commented by: Michiel Spoor (mdspoor)

Dmitry,

>True, but only fot the queries that don't read blobs. And it will decrease performance of the queries that read blobs along with other fields.

So it depends on the type of data in the blob and subsequently the way the data is retrieved by the application...
For me that would be all the more reason to be interested to easily manipulate the way the BLOB's are stored.

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

ODS12 introduced two kinds of data pages - primary, where all primary record versions are stored, and secondary, where primary record versions are not stored (it contains backversions, fragments and blobs).
Blob records are stored at secondary data pages in ODS12, therefore it never could be at the same page as primary record version.
It was not intentional change, btw. We could change it, of course, but first we should decide if it must be changed.

Note, before ODS12 blob records could be stored at the same page as primary record version or at another page - it was not deterministic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant