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

Database size increases highly while executing select query [CORE3953] #4286

Open
firebird-automations opened this issue Oct 12, 2012 · 10 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Alex Kurov (alex.kurov)

Is related to CORE3952
Is related to CORE4109
Relate to CORE3951

Attachments:
TEST_clear.zip

Votes: 1

Test base is included

Test query: select (select * from BASE64_ENCODE(photo)) from personphoto

This procedure automates BASE64_ENCODE and it really works with small blobs (<32k), but it test case base size increases 5kk after query execution

@firebird-automations
Copy link
Collaborator Author

Commented by: Alex Kurov (alex.kurov)

test base

@firebird-automations
Copy link
Collaborator Author

Modified by: Alex Kurov (alex.kurov)

Attachment: TEST_clear.zip [ 12239 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @mrotteveel

Might be related to CORE3952

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Exactly.

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

Link: This issue is related to CORE3952 [ CORE3952 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Vladimir Arkhipov (arkinform)

We have the same problem with text blobs and the main reason is that we can not use varchar instead of blobs because of limit 32k.
Do you have any plans to introduce unlimited varchar type like "text" in Postgres?
It might help to avoid nontarget use of blobs.

@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

There is no "unlimited" thing in computing. It will be limited by memory, disk or combination of the two. Calling it text, blob or clob changes nothing.

So it's a matter of design and implementation requirements and decisions:
1) Add blob garbage collection in PSQL
2) Make virtual (on the fly) concatenation
3) Make hints or another manner to make new blobs go to temp space
4) Add a system package (set of functions) to deal with blobs in PSQL

@firebird-automations
Copy link
Collaborator Author

Commented by: Vladimir Arkhipov (arkinform)

I think will be usefull 2 options:
1) Syntax in PSQL to declare type "text", computed in operating memory and compatible with varchars and text blobs (like simple string type, for example, in Pascal)
2) Syntax in PSQL to declare "temp" blobs with automatic garbage collection (blobs created in temp directory and deleted after usage)

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

Link: This issue is related to CORE4109 [ CORE4109 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

Link: This issue relate to CORE3951 [ CORE3951 ]

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