Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range |
Дата | |
Msg-id | 6719.1493476491@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range (Dmitriy Sarafannikov <dsarafannikov@yandex.ru>) |
Ответы |
Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range
|
Список | pgsql-hackers |
Dmitriy Sarafannikov <dsarafannikov@yandex.ru> writes: >> Maybe we need another type of snapshot that would accept any >> non-vacuumable tuple. I really don't want SnapshotAny semantics here, > If I understood correctly, this new type of snapshot would help if > there are long running transactions which can see this tuples. > But if there are not long running transactions, it will be the same. > Am i right? Right. You haven't shown us much about the use-case you're concerned with, so it's not clear what's actually needed. > And what about don’t fetch actual min and max values from indexes > whose columns doesn’t involved in join? We don't fetch that info unless we need it. I'm not entirely certain, but there could be cases where a single planning cycle ends up fetching that data more than once. (There's caching at the RestrictInfo level, but that might not be enough.) So a line of thought that might be worth looking into is adding a lower layer of caching to make sure it's not done more than once per plan. Again, whether this saves anything would depend a lot on specific use-cases. regards, tom lane
В списке pgsql-hackers по дате отправления: