Re: Reducing tuple overhead
От | Alvaro Herrera |
---|---|
Тема | Re: Reducing tuple overhead |
Дата | |
Msg-id | 20150430030718.GO4369@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Reducing tuple overhead (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert Haas wrote: > On Mon, Apr 27, 2015 at 5:01 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: > > The problem with just having the value is that if *anything* changes between > > how you evaluated the value when you created the index tuple and when you > > evaluate it a second time you'll corrupt your index. This is actually an > > incredibly easy problem to have; witness how we allowed indexing > > timestamptz::date until very recently. That was clearly broken, but because > > we never attempted to re-run the index expression to do vacuuming at least > > we never corrupted the index itself. > > True. But I guess what I don't understand is: how big a deal is this, > really? The "uncorrupted" index can still return wrong answers to > queries. The fact that you won't end up with index entries pointing > to completely unrelated tuples is nice, but if index scans are missing > tuples that they should see, aren't you still pretty hosed? As I recall, there's a desire not to run expressions when vacuuming, because to run them means getting a snapshot, in case any functions look at database state; and you can't get a snapshot while vacuuming because that means the vacuum gets visible to concurrent processes; in particular they keep all processes' xmin from moving forward. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: