On Fri, 3 Sep 2010, Tom Lane wrote:
Gerhard Wiesinger writes:
8.3 query plans: http://www.wiesinger.com/tmp/pg_perf_83_new.txt
8.4 quey plans: http://www.wiesinger.com/tmp/pg_perf_84.txt
Hmm. The 8.3 plan is indeed assuming that the number of rows will stay
constant as we bubble up through
Gerhard Wiesinger writes:
> Back to the original problem:
Finally ;-)
> 8.3 query plans: http://www.wiesinger.com/tmp/pg_perf_83_new.txt
> 8.4 quey plans: http://www.wiesinger.com/tmp/pg_perf_84.txt
Hmm. The 8.3 plan is indeed assuming that the number of rows will stay
constant as we bubble up
On Fri, 3 Sep 2010, Tom Lane wrote:
Gerhard Wiesinger writes:
On Fri, 3 Sep 2010, Tom Lane wrote:
I think what may be happening here is that a postgres executable expects
to find itself in a full installation tree, ie if it's in /someplace/bin
then the timezone files are in /someplace/share,
Gerhard Wiesinger writes:
> On Fri, 3 Sep 2010, Tom Lane wrote:
>> I think what may be happening here is that a postgres executable expects
>> to find itself in a full installation tree, ie if it's in /someplace/bin
>> then the timezone files are in /someplace/share, etc. Did you do a full
>> "ma
On Fri, 3 Sep 2010, Tom Lane wrote:
Gerhard Wiesinger writes:
On Fri, 3 Sep 2010, Tom Lane wrote:
Doh. I hadn't looked closely at that. Probably you want
/usr/share/zoneinfo --- at least that's what the Red Hat RPMs use.
I tried even before I wrote to the mailinglist without success:
./c
Gerhard Wiesinger writes:
> On Fri, 3 Sep 2010, Tom Lane wrote:
>> Doh. I hadn't looked closely at that. Probably you want
>> /usr/share/zoneinfo --- at least that's what the Red Hat RPMs use.
> I tried even before I wrote to the mailinglist without success:
> ./configure
I'd definitely sugges
On Fri, 3 Sep 2010, Tom Lane wrote:
Gerhard Wiesinger writes:
On Fri, 3 Sep 2010, Tom Lane wrote:
Huh. Try strace'ing the process to see what it's doing.
It tries to find something in /usr/share/ ...
Ok, I think from the compile time options:
./configure --with-system-tzdata=/usr/share
Kaloyan Iliev Iliev wrote:
> I thing they should be access only if there are rows from the
> where. Why the left join executes first?
Out of curiosity, what happens if you consistently us JOIN clauses,
rather than mixing that with commas?:
explain analyze
SELECT
DD.debtid,
ADD.amount
Gerhard Wiesinger writes:
> On Fri, 3 Sep 2010, Tom Lane wrote:
>> Huh. Try strace'ing the process to see what it's doing.
> It tries to find something in /usr/share/ ...
> Ok, I think from the compile time options:
> ./configure --with-system-tzdata=/usr/share
Doh. I hadn't looked closely at
Kaloyan Iliev Iliev writes:
> I have I query which behave strangely (according to me).
> According to the first plan PG makes absolutely unnecessary seq scan on
> tables "invoices" and "domeini" and etc.
I think you might get better results if you could get this rowcount
estimate a bit more in l
On Fri, 3 Sep 2010, Tom Lane wrote:
Gerhard Wiesinger writes:
On Fri, 3 Sep 2010, Tom Lane wrote:
Not even in that pgstartup.log file you sent stderr to?
Yes, also the redirected log file is empty. Also kernel log is empty.
Huh. Try strace'ing the process to see what it's doing.
It t
Gerhard Wiesinger writes:
> On Fri, 3 Sep 2010, Tom Lane wrote:
>> Not even in that pgstartup.log file you sent stderr to?
> Yes, also the redirected log file is empty. Also kernel log is empty.
Huh. Try strace'ing the process to see what it's doing.
> BTW: Shared memory can't be any issue?
I
Hello,
I have I query which behave strangely (according to me).
According to the first plan PG makes absolutely unnecessary seq scan on
tables "invoices" and "domeini" and etc.
I thing they should be access only if there are rows from the where. Why
the left join executes first?
Then I rewrite t
On Fri, 3 Sep 2010, Tom Lane wrote:
Not even in that pgstartup.log file you sent stderr to?
I have seen cases before where Postgres couldn't log anything because of
SELinux. If this is a Red Hat based system, look in the kernel log for
AVC messages. If you see any, then SELinux is probably blo
* Tom Lane:
>> Any idea what could cause this? Do I need to provide some estimator
>> function somewhere?
>
> If you haven't, then how would you expect the planner to know that?
Perhaps it's psychic, or there is some trick I don't know about? 8-)
> Less flippantly, you really need to tell us ex
Florian Weimer writes:
> I've created a few user-defined types quite similar to uuid which we
> use to store various hashes in the database. (The types use binary
> encoding internally, but only expose hexadecimal strings externally.)
> The hashes are roughly equidistributed, so when I do a rang
I've created a few user-defined types quite similar to uuid which we
use to store various hashes in the database. (The types use binary
encoding internally, but only expose hexadecimal strings externally.)
The hashes are roughly equidistributed, so when I do a range query
which is essentially bas
Gerhard Wiesinger writes:
> On Thu, 2 Sep 2010, Tom Lane wrote:
>> Hm, you sure about that? What's in the postmaster log?
> That's the strange thing: I don't have anything in stdout/stderr log and
> in pg_log directory and even in syslog.
Not even in that pgstartup.log file you sent stderr to?
18 matches
Mail list logo
