wd writes:
> I have a long SQL with many join, the explain analyse output like
>-> Hash Left Join (cost=197749705.15..5320438982425.18
> rows=5245599776015 width=7542) (actual time=674.634..2645.293 rows=4568
> loops=1)
> Hash Cond: (p.id = ps.partner_id)
> -> Merge Join
I have a long SQL with many join, the explain analyse output like
-> Hash Left Join (cost=197749705.15..5320438982425.18
rows=5245599776015 width=7542) (actual time=674.634..2645.293 rows=4568
loops=1)
Hash Cond: (p.id = ps.partner_id)
-> Merge Join (cost=197747693.55..788
Hi,
It's been covered a few times in the past,
http://www.postgresql.org/message-id/banlktimft4ohqkb6y7m4wqrffpwnutp...@mail.gmail.com
http://postgresql.1045698.n5.nabble.com/partial-indexes-not-used-on-parameterized-queries-td2121027.html
but in a nutshell, partial indices do not play nicely wit
2013/2/3 Tom Lane :
> Jason Dusek writes:
>> The idea would be, to store information about the last XID in
>> the last sync and search for XIDs committed since then upon
>> reconnecting for sync. Perhaps `txid_current_snapshot()'
>> preserves enough information. Is this a plausible technique?
>
>
Jason Dusek writes:
> The idea would be, to store information about the last XID in
> the last sync and search for XIDs committed since then upon
> reconnecting for sync. Perhaps `txid_current_snapshot()'
> preserves enough information. Is this a plausible technique?
Perfectly plausible, and ofte
On Sun, Feb 3, 2013 at 3:31 AM, Edson Richter wrote:
> Ok, I get it. Good education!
>
> Thank you very much, saved me a big headache!
>
>
Also Bruce Momjian wrote some articles about NULLs [1] and one of them is
about "NOT IN" [2]
Best Regards,
[1] http://momjian.us/main/blogs/pgblog/2013.html
On 2013-01-31, haman...@t-online.de wrote:
>
> Pavel Stehlule wrote:
>
>>> >> Hi,
>>> >>
>>> >> I am trying to match items from 2 tables based on a common string.
>>> >> One is a big table which has one column with entries like XY123, ABC44, =
>>> etc
>>> >> The table has an index on that column.
On 2013-01-28, Paul Jones wrote:
>
> Since posting this, I tried digging around in the source code. From looking
> at
> "timestamp_in" and related routines, it doesn't appear to take into account
> any LC_* environment var. And I didn't see strftime(3) used for timestamps
> (although I could h
On 2013-01-28, c k wrote:
> --bcaec5014c15b72ffb04d459337f
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
> I have two variables in pl/pgsql function.
> p_fromdate and p_todate
>
> I have another variable which represents intervals like day, month, quarter
> etc.
> p_interval as smallint, to h
On 2013-01-30, Adrian Klaver wrote:
> On 01/30/2013 02:49 AM, DANIEL CRISTIAN CRUZ wrote:
>>
>>
>> Em 29/01/2013 17:30, Adrian Klaver escreveu:
>>> Why not:
>>>
>>> DO $$
>>> plpy.warning('test, detail')
>>> $$ LANGUAGE plpythonu;
>>>
>>> In log:
>>>
>>> WARNING: test, detail
>>>
>>
>> Becau
On 2013-01-30, c k wrote:
> --bcaec54eebba86ab5904d4815b33
> Content-Type: text/plain; charset=UTF-8
>
> Thanks.
> After some hacking it solved my problems using
> select date_part('days', age('06/01/2010'::date ,'04/01/2010'::date));
>
??? you can't get there from here.
--
⚂⚃ 100% natural
-
On 2013-01-31, Rich Shepard wrote:
>I'd like to understand what I'm missing when I COPY a table to a .csv file
> but the text is not quoted.
>
>Here's an example of a command:
>
> copy chemistry to '/home/postgres/emapchem.csv' with (format CSV, header
> True, quote '"', delimiter '|');
>
12 matches
Mail list logo
