It's a slight improvement, but that could be other things as well.
I'd read that how you tune Postgres will determine how the optimizer works
on a query (sequential scan vs index scan). I am going to post all I've done
with tuning tommorow, and see if I've done anything dumb. I've found some
contr
Yes, the query operates only on indexed columns (all numeric(10)'s).
Column |Type |
Modifiers
---+-+--
---
user_account_id | numeric(10,0) |
Hi,
Josh Berkus wrote:
> Nick,
>
> > I reckon do a system scan first, and parse the current PostgreSQL conf
> > file to figure out what the settings are. Also back it up with a date
> > and time appended to the end to make sure there is a backup before
> > overwriting the real conf file. Then a b
On Sun, 12 Oct 2003, David Griffiths wrote:
> [snip]
>
> > I think you want something like:
> > UPDATE user_account SET last_name = 'abc'
> > WHERE EXISTS (SELECT 1 FROM commercial_entity ce, commercial_service cs
> > WHERE user_account.user_account_id = ce.user_account_id AND
> > ce.commercial
David Griffiths wrote:
I think you want something like:
UPDATE user_account SET last_name = 'abc'
WHERE EXISTS (SELECT 1 FROM commercial_entity ce, commercial_service cs
WHERE user_account.user_account_id = ce.user_account_id AND
ce.commercial_entity_id = cs.commercial_entity_id);
Unfort, this is s
[snip]
> I think you want something like:
> UPDATE user_account SET last_name = 'abc'
> WHERE EXISTS (SELECT 1 FROM commercial_entity ce, commercial_service cs
> WHERE user_account.user_account_id = ce.user_account_id AND
> ce.commercial_entity_id = cs.commercial_entity_id);
Unfort, this is st
Andriy Tkachuk wrote:
On Thu, 9 Oct 2003, Gaetano Mendola wrote:
Andriy Tkachuk wrote:
On Wed, 8 Oct 2003, Tom Lane wrote:
Andriy Tkachuk <[EMAIL PROTECTED]> writes:
At second. calc_total() is immutable function:
but it seems that it's not cached in one session:
It's not supposed to be.
but it's
Chris, People:
(Dropped SQL list because we're cross-posting unnecessarily)
> I am not sure I agree with you. I have done similar things with Oracle and
> found that the second query will execute much more quickly than the first.
> It could be made to work in at least two scenarios
Actually, Po
Chris,
> > PostgreSQL requires some more shared memory to cache some tables, x Mb,
> > do you want to increase your OS kernel parameters?
> >
> >Tweak shmmax and shmmall
>
> Note that this still requires a kernel recompile on FreeBSD :(
Not our fault, now is it? This would mean that we woul
Nick,
> I reckon do a system scan first, and parse the current PostgreSQL conf
> file to figure out what the settings are. Also back it up with a date
> and time appended to the end to make sure there is a backup before
> overwriting the real conf file. Then a bunch of questions. What sort of
> qu
Andrew Sullivan kirjutas P, 12.10.2003 kell 22:28:
> On Fri, Oct 10, 2003 at 09:01:12PM -0500, Ron Johnson wrote:
> >
> > > Does PostgreSQL only pick one index per table on the select statements?
> >
> > That's it's preference.
>
> As far as I know, that's all it can do. Do you know something
>
On Fri, Oct 10, 2003 at 09:01:12PM -0500, Ron Johnson wrote:
>
> > Does PostgreSQL only pick one index per table on the select statements?
>
> That's it's preference.
As far as I know, that's all it can do. Do you know something
different?
A
--
Andrew Sullivan 20
12 matches
Mail list logo