Please don't top post!
See below for my comments.
On 09/07/14 07:04, Kynn Jones wrote:
Thanks to Gavin and Martijn for their suggestions. They're both simple
good-ol' LCGs, and both avoid the need to check for collisions.
I ultimately went with a multiplicative LCG, like Martijn's, mostly
be
On Sat, Jul 5, 2014 at 8:12 AM, Edson Richter wrote:
> Thanks!
>
> I'll investigate (explain) performance for both versions.
also be advised that in most cases when you use SQL 'UNION' you really
should be using 'UNION ALL'. It's a very common mistake:
UNION: form proper set union, combine set
Thanks to Gavin and Martijn for their suggestions. They're both simple
good-ol' LCGs, and both avoid the need to check for collisions.
I ultimately went with a multiplicative LCG, like Martijn's, mostly because
I understand better how it avoids collisions, so it was easier for me to
tweak it in v
On Tue, Jul 8, 2014 at 12:40 PM, Ravi Kiran
wrote:
> hi,
>
> I am trying to learn how postgresql implements the join algorithms.
>
> So I am trying to learn about the source code of the executor precisely
> the file nodenestloop.c .
>
> In the executor file I have nodenestloop.o but no binary exe
hi,
I am trying to learn how postgresql implements the join algorithms.
So I am trying to learn about the source code of the executor precisely the
file nodenestloop.c .
In the executor file I have nodenestloop.o but no binary executor file.
I am using helios eclipse to edit the source code.
I
On Tue, Jul 8, 2014 at 2:47 AM, Spiros Ioannou wrote:
> While executing the following query through psql :
>
> SELECT me.* FROM measurement_events me JOIN msrcs_timestamps mt ON
> me.measurement_source_id=mt.measurement_source_id WHERE measurement_time >
> last_update_time
>
> there are two beha
On 7/8/2014 4:47 AM, Spiros Ioannou wrote:
While executing the following query through psql :
SELECT me.* FROM measurement_events me JOIN msrcs_timestamps mt ON
me.measurement_source_id=mt.measurement_source_id WHERE
measurement_time > last_update_time
there are two behaviors observed by post
OK. Please run what Tom suggested ( select * from pg_prepared_xacts; ), and
show us output.
Also, please run:
vacuum verbose analyze hotel_site_market;
and also show us output.
depesz
On Tue, Jul 8, 2014 at 2:39 PM, Prabhjot Sheena <
prabhjot.she...@rivalwatch.com> wrote:
> Yes i did ran it
Yes i did ran it in caesius database and not prod01 db that was a typo
there is no long running transactions. i just ran this command select
min(xact_start) from pg_stat_activity where xact_start is not null; to make
sure
Thanks
On Tue, Jul 8, 2014 at 4:43 AM, hubert depesz lubaczewski
wrote:
First question - are you sure you ran vacuum in the correct database? I.e.
in caesius?
Second - is there any long running transaction? select min(xact_start) from
pg_stat_activity where xact_start is not null; should tell you.
depesz
On Tue, Jul 8, 2014 at 12:44 PM, Prabhjot Sheena <
prabhjot.
So this is what i did but my problem is still not going away.
i shutdown the database and started it in single user mode and issued
command vacuum full
The command completed but the issue still exists
The thing i noticed is that whenever i start the database autovaccum
automatically starts on on
While executing the following query through psql :
SELECT me.* FROM measurement_events me JOIN msrcs_timestamps mt ON
me.measurement_source_id=mt.measurement_source_id WHERE measurement_time >
last_update_time
there are two behaviors observed by postgresql (8.4):
1) Either the query performs lot
Le 07/07/2014 18:28, Madhurima Das a écrit :
Hi Pujol,
Thanks a ton for your help!!
I was missing the semicolon and it works fine now..
Thanks,
Madhurima
On Mon, Jul 7, 2014 at 11:09 AM, Madhurima Das
mailto:madhurima@gmail.com>> wrote:
I just checked that anything after the line
13 matches
Mail list logo
