On Thu, 10 Aug 2017 18:06:17 +0300 Alexander Korotkov <[email protected]> wrote:
> On Wed, Aug 9, 2017 at 7:38 PM, Robert Haas <[email protected]> > wrote: > > > On Tue, Aug 1, 2017 at 4:00 PM, Ildus K > > <[email protected]> wrote: > > > It's a workaround. DatumGetTSVector and > > > DatumGetTSVectorCopy will upgrade tsvector on the fly if it > > > has old format. > > > > Hmm, that seems like a real fix, not just a workaround. If you can > > transparently read the old format, there's no problem. Not sure > > about performance, though. > > > > +1 > Ildus, I think we need to benchmark reading of the old format. There > would be tradeoff between performance of old format reading and > amount of extra code needed. Once we will have benchmarks we can > consider whether this is the solution we would like to buy. In my benchmarks when database fits into buffers (so it's measurement of the time required for the tsvectors conversion) it gives me these results: Without conversion: $ ./tsbench2 -database test1 -bench_time 300 2017/08/17 12:04:44 Number of connections: 4 2017/08/17 12:04:44 Database: test1 2017/08/17 12:09:44 Processed: 51419 With conversion: $ ./tsbench2 -database test1 -bench_time 300 2017/08/17 12:14:31 Number of connections: 4 2017/08/17 12:14:31 Database: test1 2017/08/17 12:19:31 Processed: 43607 I ran a bunch of these tests, and these results are stable on my machine. So in these specific tests performance regression about 15%. Same time I think this could be the worst case, because usually data is on disk and conversion will not affect so much to performance. -- --- Ildus Kurbangaliev Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
