Chester Kustarz <[EMAIL PROTECTED]> writes:
> it seems that you cannot run analyze inside a transaction:
You can in 7.3.* ...
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unreg
> begin;
> analyze foo;
> ERROR: ANALYZE cannot run inside a BEGIN/END block
>
> i am using version 7.2.3.
Time to upgrade. 7.3 / 7.4 allows this to happen.
signature.asc
Description: This is a digitally signed message part
is there any way to update the stats inside a transaction? what i have is
something like:
select count(*) from foo;
-> 0
begin;
copy foo from '/tmp/foo'; -- about 100k rows
-- run some queries on foo which perform horribly because the stats
-- are way off (100k rows v. 0 rows)
commit;
it see
At 13:40 10/31/2003, Neil Conway wrote:
On Fri, 2003-10-31 at 13:27, Allen Landsidel wrote:
> I had no idea analyze was playing such a big role in this sense.. I really
> thought that other than saving space, it wasn't doing much for tables that
> don't have indexes on the.
ANALYZE doesn't save any
Allen,
> I had no idea analyze was playing such a big role in this sense.. I really
> thought that other than saving space, it wasn't doing much for tables that
> don't have indexes on the.
Among other things, ANALYZE tells postgres how many rows are in the table. So
if you add a PK constraint
On Fri, 2003-10-31 at 13:27, Allen Landsidel wrote:
> I had no idea analyze was playing such a big role in this sense.. I really
> thought that other than saving space, it wasn't doing much for tables that
> don't have indexes on the.
ANALYZE doesn't save any space at all -- VACUUM is probably w
Nope, still 7.3.4 here.. I am very excited about 7.4 though.. almost as
excited as I am about FreeBSD 5.x going -STABLE.. it's a close race
between the two..
I'll keep this in mind for when I update though, thanks.
At 11:23 10/31/2003, Rod Taylor wrote:
If it is 7.4 beta 5 or later, I would de
At 12:10 10/31/2003, Josh Berkus wrote:
Allen,
> a) CREATE TABLE with no indexes or keys. Run the COPY (fast, ~30min), then
> CREATE INDEX on each column it's needed on, and ALTER TABLE for the pk and
> each fk needed.
Did you ANALYZE after the copy?
No, and this was my major mistake. I normally
Allen,
> a) CREATE TABLE with no indexes or keys. Run the COPY (fast, ~30min), then
> CREATE INDEX on each column it's needed on, and ALTER TABLE for the pk and
> each fk needed.
Did you ANALYZE after the copy?
> If there isn't a significant difference between all of them, performance
> wise, I
If it is 7.4 beta 5 or later, I would definitely go with A.
Adding indexes after the fact seems to be much quicker. Foreign keys use
the same algorithm prior to beta 5 regardless of timing.
A primary key and unique index will have approx the same performance (a
check for NULL isn't very costly).
10 matches
Mail list logo
