Re: psql is slow and it does not take much resources

Поиск
Список
Период
Сортировка
От Javier de la Torre
Тема Re: psql is slow and it does not take much resources
Дата
Msg-id a0174d240605030834v232ca2e3y387150b06137bd96@mail.gmail.com
обсуждение исходный текст
Ответ на Re: psql is slow and it does not take much resources  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: psql is slow and it does not take much resources  (Joe Healy <joe@omc-international.com.au>)
Re: psql is slow and it does not take much resources  (Alban Hertroys <alban@magproductions.nl>)
Список pgsql-general
Great! Then there will be no problems.

I would use COPY but I think I can not. While moving from MySQL to
PostgreSQL I am also transforming a pair of fields, latitude,
longitude, into a geometry field, POINT, that is understood for
Potgis. I though I will not be able to use COPY when inserting data
with functions.

Thanks again all.

Javier.

On 5/3/06, Martijn van Oosterhout <kleptog@svana.org> wrote:
> On Wed, May 03, 2006 at 04:28:10PM +0200, Leif B. Kristensen wrote:
> > However, I'm wondering if there's a practical limit to how many rows you
> > can insert within one transaction?
>
> There's a limit of (I think) 2-4 billion commands per transaction. Each
> command can insert any number of tuples.
>
> So if you're doing one tuple per command that limits you to a few
> billion inserts per transaction. Ofcourse, COPY is always faster
> still...
>
> Have a nice day,
> --
> Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> > From each according to his ability. To each according to his ability to litigate.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFEWMwgIB7bNG8LQkwRAnvUAJ9YlsyGDInXKwFhsViFTJXvnUmd9ACeO5Al
> LLqOvjBshH9VXfR1SaBHMYE=
> =itek
> -----END PGP SIGNATURE-----
>
>
>

В списке pgsql-general по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: psql is slow and it does not take much resources
Следующее
От: Csaba Nagy
Дата:
Сообщение: The planner chooses seqscan+sort when there is an index on the sort column