Adam PAPAI <[EMAIL PROTECTED]> wrote ..
> Hi pgsql-performance,
>
> I've a problem with the select * on a small table.
>
I can think of two possibilities for such incredibly slow performance.
One: your table has not been VACUUMed for a long time and is full of dead
tuples. Try VACUUM FULL on i
Tom Lane wrote:
Yes.
1) It's of no value to us
2) On many platforms there is a nonzero performance penalty
I think you have your head in the ground, but its your perogative. *You*
might not care, but anyone wanting to use thread-aware libraries (and I'm
*not* talking about threading in an
I wrote
> That's what I did at first, but later I found better performance with
> a TRIGGER on the permanent table that deletes the target of an UPDATE,
> if any, before the UPDATE. [INSERT!] That's what PG does anyway, and now I
> can do
> the entire UPDATE [INSERT] in one command.
It's probably
On Dec 14, 2007 10:11 PM, Campbell, Lance <[EMAIL PROTECTED]> wrote:
> PostgreSQL: 8.2
>
>
>
> My understanding is that when one creates a large object there is no way
> to link the large object to a field in a table so that cascading delete can
> occur. Is this correct? My understanding is tha
"Craig James" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>
>> And the only reason to do that would be to work around one bug in one small
>> range of glibc versions. If you're going to use a multi-threaded library
>> (which isn't very common since it's hard to do safely for all those other
On Sun, Dec 16, 2007 at 07:34:45PM +0100, Adam PAPAI wrote:
> Why does it take cca 18-20 sec to get the results?
> Too many indexes?
You cannot possibly have VACUUMed in a long time. Try a VACUUM FULL, and then
schedule regular VACUUMs (or use autovacuum).
/* Steinar */
--
Homepage: http://www.s
Gregory Stark wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
James Mansion <[EMAIL PROTECTED]> writes:
Is there any particular reason not to ensure that any low-level
threading support in libc is enabled right
from the get-go, as a build-time option?
Yes.
1) It's of no value to us
Who is "u
On Dec 16, 2007 12:21 AM, <[EMAIL PROTECTED]> wrote:
> Loïc Marteau <[EMAIL PROTECTED]> wrote ..
> > Steve Crawford wrote:
> > > If this
> > > is correct, I'd first investigate simply loading the csv data into a
> > > temporary table, creating appropriate indexes, and running a single
> > > query
Adam PAPAI wrote:
Hi pgsql-performance,
I've a problem with the select * on a small table.
See below:
x7=# SELECT count(idn) from megjelenesek;
count
---
162
(1 row)
Why does it take cca 18-20 sec to get the results?
Too many indexes?
You likely have a huge amount of dead rows. Try
Hi pgsql-performance,
I've a problem with the select * on a small table.
See below:
x7=# EXPLAIN ANALYZE select * from megjelenesek;
QUERY PLAN
"Tom Lane" <[EMAIL PROTECTED]> writes:
> James Mansion <[EMAIL PROTECTED]> writes:
>> Is there any particular reason not to ensure that any low-level
>> threading support in libc is enabled right
>> from the get-go, as a build-time option?
>
> Yes.
> 1) It's of no value to us
> 2) On many platfor
James Mansion <[EMAIL PROTECTED]> writes:
> Is there any particular reason not to ensure that any low-level
> threading support in libc is enabled right
> from the get-go, as a build-time option?
Yes.
1) It's of no value to us
2) On many platforms there is a nonzero performance penalty
Gregory Stark wrote:
1) No Postgres function is guaranteed to be thread-safe so you better protect
against concurrent calls to Postgres API functions. Also Postgres functions
use longjmp which can restore the stack pointer to a value which may have
been set earlier, possibly by another t
[EMAIL PROTECTED] wrote:
Hello
i have a python script to update 60 rows to one table from a csv file in my
postgres database and it takes me 5 hours to do the transaction...
I'm on debian etch with 8.1 postgres server on a 64 bits quad bi opteron.
I have desactived all index except the pr
14 matches
Mail list logo
