Re: Postgresql's table & index compared to that of MySQL
От | Thom Brown |
---|---|
Тема | Re: Postgresql's table & index compared to that of MySQL |
Дата | |
Msg-id | AANLkTinnCH7XygYUA4sGzmqdS8V3A=_OoufKVpbYZYbC@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Postgresql's table & index compared to that of MySQL (Thom Brown <thom@linux.com>) |
Список | pgsql-general |
On 17 August 2010 16:00, Thom Brown <thom@linux.com> wrote: > On 17 August 2010 13:45, Thom Brown <thom@linux.com> wrote: >> On 17 August 2010 04:05, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Andy <angelflow@yahoo.com> writes: >>>> Your results of 867MB for Postgresql & 3,576 MB for InnoDB are surprising. Do you know why it is so much smaller forPostgresql? Are there any indexes? >>> >>> If I understood the original report correctly, they were complaining >>> mostly about index size, so a table without indexes certainly isn't >>> a real helpful comparison. >> >> Yeah, I did attempt to create a full text GIN index on that last >> night, but it was taking ages and it was getting late, so abandoned >> it. If you're interested, I set up one on MySQL's version (MyISAM of >> course) and it was around 108 MB. The problem is, if PostgreSQL's >> index was, say, 600 MB, it might still not be fair to compare it since >> they make not really be equivalent. >> >> But those slides leave a lot of important information out. And even >> if it clearly explained everything in detail, they're talking about >> 7.4 and 8.0. The world has changed since then. >> > Okay, I've left the creation of 2 full text indexes, one using GIN and > another using GiST. GIN comes up with 72 MB and GiST 21 MB. > > But again, this is all rather synthetic and the data I've used > contains duplicate content. As for VACUUM performance hits, this has > changed since 8.0 too. 8.2 came with more efficient index VACUUMing. > 8.3 introduced Heap-Only Tuples which allow dead tuples to be reused. > And VACUUM is also tunable in the config. > Actually, if MySQL won't return anything which occurs in 50% or more of the rows, and all the rows in my test were duplicates, what's it spending 108 MB on if there's no full text query I can use which can return results? -- Thom Brown Registered Linux user: #516935
В списке pgsql-general по дате отправления: