Why fetch a row is more slow than a 'selec * from'
От | Ing.Edmundo.Robles.Lopez |
---|---|
Тема | Why fetch a row is more slow than a 'selec * from' |
Дата | |
Msg-id | 4EB7FABB.2020100@sensacd.com.mx обсуждение исходный текст |
Ответы |
Re: Why fetch a row is more slow than a 'selec * from'
|
Список | pgsql-general |
Hello I've been looking for ways to optimize a query. I have a table with 120,000 records. When searched on: select * from big_table takes to run: 3 min. I wanted to use cursors and the query with big_table, it taked 11 minutes. It caught my attention on a small_table (100 records) because the time, with cursors, were reduced by half. The EXPLAIN ANALYZE: indicates that a search is sequential, but has a primary key Will have some advice to optimize the response time of the visit? there is nothing to do? :( El contenido de este correo electrónico y sus archivos adjuntos son privados y confidenciales y va dirigido exclusivamentea su destinatario. No se autoriza la utilización, retransmisión, diseminación, o cualquier otro uso de estainformación por un receptor o entidades distintas al destinatario. Si recibe este correo sin ser el destinatario sele solicita eliminarlo y hacerlo del conocimiento del emisor. La empresa no se hace responsable de transmisiones o comunicacionesno autorizadas o emitidas por personas ajenas a sus colaboradores utilizando éste medio electrónico. The content of this email and its attached files are private and confidential and intended exclusively for the use of theindividual or entity to which they are addressed. The retransmission, dissemination, or any other use of this informationother than by the intended recipient is prohibited. If you have received this email in error please delete itand notify the sender. The company cannot be held liable for unauthorized electronic transmissions or communications,nor for those emitted by non-company individuals and entities.
В списке pgsql-general по дате отправления: