) > 0
>
>
Well, there is nothing wrong with the much simpler
where cheap_function(item) > 0 and where very_expensive_function(item) > 0.
It's all about the order of evaluation.
Thanks,
Han Holl
---(end of broadcast)---
TIP 1:
nfluence on the order in case of lazy
evaluation.
Han Holl
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
case, indexes don't help.
Do you know if functionality like this has ever be considered ?
I seem to encounter many queries where the order in the where clause matters,
(but then we have a kind of weird database).
Cheers,
Han Holl
---(end of broadcast)--
tion ?
Or is there a hook in the system that would allow me too look at and maybe
reorder expressions before they are executed ?
Cheers,
Han Holl
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgre
On Tuesday 29 November 2005 00:42, Jerry LeVan wrote:
> /var/tmp/rpm-tmp.58757: line 79: fg: no job control
> error: Bad exit status from /var/tmp/rpm-tmp.58757 (%prep)
[ cut ]
> Any suggestions?
>
Well, I would look at what line 79 of /var/tmp/rpm-tmp.58757 has to say.
Cheer
On Thursday 20 October 2005 23:48, Tom Lane wrote:
> Give us a test case to demonstrate this assertion. It works as expected
> AFAICT.
>
Ok, it has to do with C functions:
#include
#include
#include
PG_FUNCTION_INFO_V1(plg_cfie);
Datum
plg_cfie(PG_FUNCTION_ARGS)
{
struct timeval befo
y to come with something more concrete.
Thanks,
Han Holl
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
o functions, and two
different update rules with a select each) but in _all_ cases the second
function is executed before the first, or possibly at the same time (but I
didn't think the backend is threaded).
Is this known behaviour, and what can I do to change it?
Thanks in advance for any sugge
ch between full statement
logging and quieter behaviour.
None of our applications is using this format, that's for sure.
Cheers
Han Holl
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
orted in LOCAL5.
Because it's shorter that a complet postgresql.conf,here's the diff against
/usr/share/pgsql/postgresql.conf.sample, from postgresql-8.0.3-1PGDG for RH9.
Have I missed something ?
Cheers,
Han Holl
--- /usr/share/pgsql/postgresql.conf.sample 2005-09-22 1
t surnames are just too unevenly distributed.
But in 99% of all cases the guess is right, and by making it a nested query I
could improve 1% and worsen 99%.
Cheers,
Han Holl
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
um.
Is this hardcoded, or can I set a higher maximum somewhere ?
If the only penalty is slower analyzing, I don't care: we analyze at night
when these system are idle.
Cheers,
Han Holl
---(end of broadcast)---
TIP 4: Have you
atum = '1966-01-01'::date) AND ((naamvrouw)::text
~~ 'vos%'::text))
Total runtime: 775.068 ms
(6 rows)
I got a similar problem with a functional index, but I guess my only option is
to create a real column with the results of the function, and replace the
functional index with a
to inform it about the wildly uneven distribution of surnames
(this must be even worse in China).
A third possibility would be to rewrite such a query as a nested query: is
there a rewrite query - hook (like apaches mod_rewrite) available ? Or is
there a somewhere a proxy-server that coul
>
Well, I suspect that something is not equal as well. The trouble is I can't
seem to find it.
We're going to replay what happened on a different machine, and hopefully will
find something.
Thanks,
Han Holl
---(end of broadcast)---
TIP 6: explain analyze is your friend
n't
need tuning on 7.4.3 ? (Main table has about 1.7 million records).
Any suggestions welcome.
Cheers,
Han Holl
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
cuum full would include analyze, wich I see now it doesn't.
I'm not a database administrator, and I'm afraid it shows. I'm going to read a lot of docs in the coming months, because real people depend on reasonable performance of our databases.
Cheers, and thanks again,
Han H
On Tuesday 04 October 2005 22:26, [EMAIL PROTECTED] wrote:
> Just a guess but have you tried using an in clause?
>
> select something from table where fase in ('1' , '2');
>
Not surprisingly, this also does a sequential scan on the table. (It would be
_very_ diffcult to see that this is a union,
ot of typing, and the first formulation has a
more natural feel to it.
Is there a way to convince the planner to use the fase index for this type of
query, or is there a hook somewhere that I missed that allows me to rewrite
a query like the above with a server-side function ?
twice (if
> > it's not null) ?
>
> You can do something like this:
>
> select f from
> (select expensive_function(table) as f from table offset 0) ss
> where f is not null;
>
Thanks.
I think I can safely say I wouldn't have invented this magic in a year.
a server side c-function doing a
syslog, when syslog was not enabled in the postgresql.conf file.
Once I had rebuild the RPMS and erased the compat libs, everything was fine.
Cheers,
Han Holl
---(end of broadcast)---
TIP 6: explain analyze is your friend
that doesn't do anything for me.
Of course I can do a select into, but my guess is it would be even more
expensive than evaluating these functions twice.
Thanks in advance,
Han Holl
---(end of broadcast)---
TIP 5: don't forget to inc
of a problematic
configuration on the machine of the packager.
I did a rebuild from the source rpm, and now the phony dependencies are gone.
Cheers,
Han Holl
---(end of broadcast)---
TIP 6: explain analyze is your friend
23 matches
Mail list logo
