Hello,
Before the week end I tried to change the index, but even with the
mono-column index on differents columns, the estimated number of rows
from dwhinv is 1.
Anyone have a suggestion, what can I check ?
thx
damien hostin a écrit :
Hello,
I try to make a query run quicker but I don't
Hello.
I have a tree-like table with a three-field PK (name, date, id) and one
parent field.
It has 5k to 6k records as of now, but it will hold about 1 million
records.
I am trying the following WITH RECURSIVE query:
WITH RECURSIVE t AS (
SELECT par.id AS tid, par.name, p
On Fri, Jul 2, 2010 at 8:30 AM, Craig Ringer wrote:
Yeah, if you're in a weird virtualized environment like that you're
likely to have problems...
On Sat, 3 Jul 2010, Rajesh Kumar Mallah wrote:
Thanks for thinking about it.I do not understand why u feel OpenVz is weird.
at the most its not ver
Hello everyone,
We've recently finished developing a bigger webapplication, and we are
about to put it online.
I ran some load tests yesterday, and configured 'slow query' logging
beforehand, so I could see if there might be a performance bottleneck
in the PG. While I discovered no real problems,
Jens,
* Jens Hoffrichter (jens.hoffrich...@gmail.com) wrote:
> I'm just curious if there is any way to improve the performance of
> those queries. I'm seeing SeqScans in the EXPLAIN ANALYZE, but nothing
> I have done yet has removed those.
SeqScans aren't necessairly bad. Also, providing your po
> A clarification of terms may help to start. The "terminals per
> warehouse" in the scripts correlates to the number terminals emulated.
> An emulated terminal is tied to a warehouse's district. In other
> words, the number of terminals translates to the number of districts
> in a warehouse ac
On Thu, Jul 1, 2010 at 6:34 PM, Michal Fapso wrote:
> It took about 4.5 seconds. If I rerun it, it takes
> less than 2 miliseconds, but it is because of the cache. I need to
> optimize the first-run.
>
> laptop ASUS, CPU dual core T2300 1.66GHz, 1.5G RAM
>
> EXPLAIN ANALYZE SELECT h1.docid
> FROM
On Fri, Jul 2, 2010 at 1:40 AM, Sachin Kumar wrote:
> At times we have observed that postgres stops responding for several
> minutes, even couldn’t fetch the number of entries in a particular table.
> One such instance happens when we execute the following steps:
Sounds sort of like a checkpoint
On 05/07/10 19:36, Jens Hoffrichter wrote:
> Hello everyone,
>
> We've recently finished developing a bigger webapplication, and we are
> about to put it online.
>
> I ran some load tests yesterday, and configured 'slow query' logging
> beforehand, so I could see if there might be a performance b
On Mon, Jul 5, 2010 at 5:36 AM, Jens Hoffrichter
wrote:
> Hello everyone,
>
> We've recently finished developing a bigger webapplication, and we are
> about to put it online.
If you're checking for bools, and 99.99% of the result is just true or
just false, look at creating partial indexes on the
10 matches
Mail list logo
