2007/8/5, Heikki Linnakangas <[EMAIL PROTECTED]>:
>
>
> I don't remember a bug like that. Where did you read that from?
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
Partially I found that one in the PostgreSQL Documentation for the
7.x.xversions under the command
Hello list,
We have a database keeping track of old files on different computers.
We have now added some search functionality to this system.
The problem is that on some searches it is really really slow and the
problem lies in the planner are using seq scans on tables with over
20 million ro
On mán, 2007-08-06 at 00:10 -0700, Sven Clement wrote:
>
>
> 2007/8/5, Heikki Linnakangas <[EMAIL PROTECTED]>:
>
> I don't remember a bug like that. Where did you read that
> from?
>
> --
> Heikki Linnakangas
> EnterpriseDB http://ww
Sven Clement wrote:
> Partially I found that one in the PostgreSQL Documentation for the
> 7.x.xversions under the command REINDEX where they claim that you
> should run a
> reindex under certain circumstances and for my comprehension this says that
> with some access pattern (as ours (major writes
Ok thanks everybody for the calrification, after all now I allready learned
something new... ;)
My employer is currently thinking about migration to 8.2.x because of your
feedback, so I think that the problem could be resolved... ;)
Thanks to everyone...
Sven Clement
2007/8/6, Heikki Linnakanga
Hi list,
I'm having a weird acting query which simply retrieves some files
stored in a db which are related to a specific archive and also has a
size lower than 1024 bytes.
Explain analyze below. The first one is with seq-scan enabled and the
other one with seq-scans disabled. The weird thi
"Henrik Zagerholm" <[EMAIL PROTECTED]> writes:
> Hi list,
>
> I'm having a weird acting query which simply retrieves some files stored in a
> db
> which are related to a specific archive and also has a size lower than 1024
> bytes.
> Explain analyze below. The first one is with seq-scan enabled
6 aug 2007 kl. 15:07 skrev Gregory Stark:
"Henrik Zagerholm" <[EMAIL PROTECTED]> writes:
Hi list,
I'm having a weird acting query which simply retrieves some files
stored in a db
which are related to a specific archive and also has a size lower
than 1024
bytes.
Explain analyze below. T
Henrik Zagerholm <[EMAIL PROTECTED]> writes:
> ... FROM tbl_file_structure
> JOIN tbl_file ON pk_file_id = fk_file_id
> JOIN tbl_structure ON pk_structure_id = fk_structure_id
> JOIN tbl_archive ON pk_archive_id = fk_archive_id
> JOIN tbl_share ON pk_shar
"Henrik Zagerholm" <[EMAIL PROTECTED]> writes:
> Ahh, my bad. It is a very small table but I have an unique index.
> CREATE UNIQUE INDEX tbl_filetype_suffix_idx ON tbl_filetype_suffix
> USING btree (filetype_suffix);
Well it can't use that to help with a join. If you had an index on
lower(filet
Henrik Zagerholm <[EMAIL PROTECTED]> writes:
> WHERE file_indexed IS FALSE
> AND file_copied IS TRUE
> AND file_size < (1024)
>
6 aug 2007 kl. 16:58 skrev Tom Lane:
Henrik Zagerholm <[EMAIL PROTECTED]> writes:
... FROM tbl_file_structure
JOIN tbl_file ON pk_file_id = fk_file_id
JOIN tbl_structure ON pk_structure_id = fk_structure_id
JOIN tbl_archive ON pk_archive_id = fk_archive_id
Thanks Merlin. I was running both via ssh so it effectively these were
local results. I will try to isolate the issue to a single statement. But
I think you have answered the larger question i.e. there is no well known
situation where this happens so I should expect to see roughly the same
perfo
Decibel! <[EMAIL PROTECTED]> writes:
> Interesting. I'm guessing that ext3 has to sync out the entire journal
> up to the point in time that fsync() is called, regardless of what
> files/information the journal contains. Fortunately I think it's common
> knowledge to mount PostgreSQL filesystems wi
Henrik Zagerholm wrote:
> I know the query retrieves way more which is really necessary to show to
> the user so I would gladly come up with a way to limit the query so the
> GUI doesn't hang for several minutes if a user does a bad search.
> The problem is that I don't know a good way of limit the
6 aug 2007 kl. 21:47 skrev Heikki Linnakangas:
Henrik Zagerholm wrote:
I know the query retrieves way more which is really necessary to
show to
the user so I would gladly come up with a way to limit the query
so the
GUI doesn't hang for several minutes if a user does a bad search.
The prob
6 aug 2007 kl. 17:31 skrev Tom Lane:
Henrik Zagerholm <[EMAIL PROTECTED]> writes:
WHERE file_indexed IS FALSE
AND file_copied
IS TRUE
AND file_siz
Henrik Zagerholm <[EMAIL PROTECTED]> writes:
> At what point does the planner choose seq scans?
When it thinks it's cheaper than the other way. There's no hard and
fast answer. The immediate problem you've got is that the estimated
size of the tbl_file/tbl_filetype_suffix join is off by a factor
18 matches
Mail list logo
