Re: Porting MSSQL to PGSQL (Was: [OT] MySQL is bad, but
От | Andrew Dunstan |
---|---|
Тема | Re: Porting MSSQL to PGSQL (Was: [OT] MySQL is bad, but |
Дата | |
Msg-id | 44724C53.2090907@dunslane.net обсуждение исходный текст |
Ответ на | Re: Porting MSSQL to PGSQL (Was: [OT] MySQL is bad, but THIS bad?) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Porting MSSQL to PGSQL (Was: [OT] MySQL is bad, but THIS bad?)
|
Список | pgsql-hackers |
Tom Lane wrote: >"Jim C. Nasby" <jnasby@pervasive.com> writes: > > >>If there was more information than the tuplestore could keep in memory, >>then a TIDstore might be faster, but only if it resulted in reading from >>the heap sequentially, or very near it. >> >> > >That's easily arranged, use a bitmap indexing data structure. > >I think we could probably even live with the structure becoming lossy >under memory pressure: AFAICS, all rows modified by a single query ought >to have the same XMIN/CMIN (or XMAX/CMAX for deleted rows), so it should >be possible to verify whether a particular row is one of the interesting >ones or not. > >I think the hard part of this task is designing the API for access to >the rowsets from triggers. > > > > How expensive is this going to be, especially for huge numbers of rows? Would it be done for all queries, or just those with a per statement trigger, or only when explicitly requested? cheers andrew
В списке pgsql-hackers по дате отправления: