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

bug: free page can not use again #15

Closed
yjhjstz opened this issue Sep 9, 2021 · 6 comments
Closed

bug: free page can not use again #15

yjhjstz opened this issue Sep 9, 2021 · 6 comments

Comments

@yjhjstz
Copy link

yjhjstz commented Sep 9, 2021

ivfflatbulkdelete() {
....
/* Set to first free page */
if (!BlockNumberIsValid(insertPage))
insertPage = searchPage;
...
}

Here only set the first free page, other deleted pages can not be used anymore, this caused index grow larger and larger.

any solution? thanks.

@ankane
Copy link
Member

ankane commented Sep 9, 2021

Hey @yjhjstz, existing pages with free space are reused (pages aren't deleted) - see InsertTuple function.

@ankane ankane closed this as completed Sep 9, 2021
@yjhjstz
Copy link
Author

yjhjstz commented Sep 9, 2021

yes, but if marked insertPage have N pages, How to manage N free pages ?

@ankane
Copy link
Member

ankane commented Sep 9, 2021

insertPage is only a single page. InsertTuple will start at insertPage and follow nextblkno until it finds a page with free space.

@yjhjstz
Copy link
Author

yjhjstz commented Sep 10, 2021

I see, but to find the free page to insert must seq scan the list , not efficient.
refer to contrib/bloom

/* Metadata of bloom index */
typedef struct BloomMetaPageData
{
	uint32		magickNumber;
	uint16		nStart;
	uint16		nEnd;
	BloomOptions opts;
	FreeBlockNumberArray notFullPage;
} BloomMetaPageData;

is that ok ?

@ankane
Copy link
Member

ankane commented Sep 10, 2021

There are more efficient ways, but I'd like to keep it simple for now. I don't think it'll be an issue for typical usage patterns (in the worst case scenario, it'll end up scanning the list once after a vacuum). Tables and some index types use a free space map, but pgvector needs one for each list (rather than one for the entire index, which isn't supported). Using an array like Bloom indexes would probably work, but it'll add more complexity.

@ankane
Copy link
Member

ankane commented Feb 6, 2022

Hey @yjhjstz, just fyi, found a bug in the vacuum code that caused indexes to not reuse space at all. There's a fix in 0.2.4 (and a test case to prevent regressions - it still uses a single insertPage, but there was a logic error).

You can shrink existing indexes with:

-- Postgres 12+
REINDEX INDEX CONCURRENTLY index_name;

-- Postgres < 12
CREATE INDEX CONCURRENTLY temp_name ON table USING ivfflat (column opclass);
DROP INDEX CONCURRENTLY index_name;
ALTER INDEX temp_name RENAME TO index_name;

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

No branches or pull requests

2 participants