On Sun, Feb 12, 2006 at 10:25:28PM +0200, Adnan DURSUN wrote:
> My database has an SQL function. The result comes in 30-40 seconds
> when i use the SQL function. On the other hand; The result comes
> 300-400 milliseconds when i run the SQL statement. Any idea ??
Have you analyzed the tables? If t
Hi, Aaron,
Aaron Turner wrote:
> 4) Does decoding the data (currently base64) and storing the binary
> data improve the distribution of the index, thereby masking it more
> efficent?
Yes, but then you should not use varchar, but a bytea.
If your data is some numer internally, numeric or decimal
If you have only recently analyzed the tables in the query, close your psql
session (if that's what you were using) and then restart it. I've gotten burned
by asking a query using the function, which I believe is when PG creates the
plan for the function, and then making significant changes to t
Hi
all,
My
database has an SQL function. The result comes in 30-40 seconds
when i use the SQL function. On the other hand; The result comes
300-400 mill
On 2/12/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Aaron Turner <[EMAIL PROTECTED]> writes:
> > Well before I go about re-architecting things, it would be good to
> > have a strong understanding of just what is going on. Obviously, the
> > unique index on the char(48) is the killer. What I don't k
On 2/12/06, Marc Morin <[EMAIL PROTECTED]> wrote:
> From your config, a check point will be forced when
>
> (checkpoint_segments * 16 M) < rows * (8K/N*h + (1-h)*8K) * B
>
> Where h is the "hitrate" or correlation between the update scan and the
> index. Do you have a sense of what this is?
I know
We've done a lot of testing on large DB's with a lot of "inserts" and
have a few comments.
The updates are "treated" as a large "insert" as we all know from pg's
point of view.
We've run into 2 classes of problems: excessing WAL checkpoints and
affects of low correlation.
WAL log write's full 8K
Aaron Turner <[EMAIL PROTECTED]> writes:
> Well before I go about re-architecting things, it would be good to
> have a strong understanding of just what is going on. Obviously, the
> unique index on the char(48) is the killer. What I don't know is:
You have another unique index on the integer pr
