On Tue, 2006-02-07 at 18:59 -0600, Jim C. Nasby wrote:
> I'm honestly somewhat surprised someone hasn't run into this problem
> with partitioning yet; or maybe everyone who needs to do long
> transactions just shoves those off to slony slaves...
All DDL takes locks, on all DBMS.
Best Regards, Si
Hi, Christopher,
Christopher Browne wrote:
> Right. And part of the trouble is that you lose certainty that you
> have covered off transaction wraparound.
Yes. Vacuum (full) serve at least four purposes:
- TID wraparound prevention
- obsolete row removal
- table compaction
- giving space back
Postgres doesn't seem to optimize away unnecessary joins in a view
definition when the view is queried in such a way that the join need not
be executed. In the example below, I define two tables, foo and bar,
with a foreign key on bar referencing foo, and a view on the natural
join of the tables.
I'm specifically interested in the default C Locale; but if there's a
difference in the answer for other locales, I'd like to hear about
that as well.
Thanks in Advance,
Ron
---(end of broadcast)---
TIP 5: don't forget to increase your free spa
Jacob Costello <[EMAIL PROTECTED]> writes:
> Postgres doesn't seem to optimize away unnecessary joins
There is no such thing as an unnecessary join, unless you are willing to
stake the correctness of the query on constraints that could be dropped
after the query is planned. Until we have some inf
On Wed, 8 Feb 2006, Jacob Costello wrote:
> Postgres doesn't seem to optimize away unnecessary joins in a view
> definition when the view is queried in such a way that the join need not
> be executed. In the example below, I define two tables, foo and bar,
> with a foreign key on bar referencing
On Wed, 2006-02-08 at 09:11 -0500, Ron wrote:
> I'm specifically interested in the default C Locale; but if there's a
> difference in the answer for other locales, I'd like to hear about
> that as well.
The size hit will be effectively zero if your data is mainly of the
ASCII variety, since ASCI
Hi, Mahesh,
Mahesh Shinde wrote:
> Does vacuum improves the performance of the database search.. As if now I
> have a table who is having a records 70 lac and daily appx 10-15 thousand
> rows get added. so please let me know which type of vacuum I should prefer.
> I am accessing a data using jav
In an attempt to save myself some time, I thought I ask The Community
if anyone has guidance here.
HW: Intel PM (very likely to be upgraded to an AMD Turion when the
proper HW becomes available) w/ 2GB of RAM (shortly to be 4GB) and a
5400rpm 100GB HD (will be dual 7200rpm 160GB HD's as soon
Markus Schaber wrote:
Does vacuum improves the performance of the database search.. As if now I
have a table who is having a records 70 lac and daily appx 10-15 thousand
rows get added. so please let me know which type of vacuum I should prefer.
I am accessing a data using java application which
Hi, Tim,
Tim Allen schrieb:
>> I don't know what "70 lac" means.
> One lac (also spelt "lakh") is one hundred thousand. And one crore is
> ten million. Indians count differently from the rest of the world :-).
Okay, so he talks about 7 million rows.
Thank you.
Markus
--
On Wed, Feb 08, 2006 at 05:05:02PM -0500, Ron wrote:
> In an attempt to save myself some time, I thought I ask The Community
> if anyone has guidance here.
>
> HW: Intel PM (very likely to be upgraded to an AMD Turion when the
> proper HW becomes available) w/ 2GB of RAM (shortly to be 4GB) and
12 matches
Mail list logo
