Re: [HACKERS] Varying results when using merge joins overpostgres_fdw vs hash joins
От
Corey Huinker
Тема
Re: [HACKERS] Varying results when using merge joins overpostgres_fdw vs hash joins
Дата
Msg-id
CADkLM=cUQTm3UfWYFkn9F_3Ptkf1Y_pmZBcK+B15JArZPrB0hw@mail.gmail.com
Ответ на
Список
Дерево обсуждения
[HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins Corey Huinker <corey.huinker@gmail.com>
Re: [HACKERS] Varying results when using merge joins overpostgres_fdw vs hash joins Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Re: [HACKERS] Varying results when using merge joins overpostgres_fdw vs hash joins Corey Huinker <corey.huinker@gmail.com>
Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Varying results when using merge joins overpostgres_fdw vs hash joins Corey Huinker <corey.huinker@gmail.com>
Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Varying results when using merge joins overpostgres_fdw vs hash joins David Kohn <david.kohn@moat.com>
Re: [HACKERS] Varying results when using merge joins overpostgres_fdw vs hash joins Peter Geoghegan <pg@bowt.ie>
Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Varying results when using merge joins overpostgres_fdw vs hash joins Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Varying results when using merge joins overpostgres_fdw vs hash joins Peter Geoghegan <pg@bowt.ie>
Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Varying results when using merge joins overpostgres_fdw vs hash joins Peter Geoghegan <pg@bowt.ie>
I'm not sure whether there's a way to fix this that doesn't break other
cases. We could retrieve the pg_database.datcollate string from the
remote, but that doesn't necessarily match up with any collation name
we know about locally. One pretty common failure mode would be that
the datcollate string isn't a canonical spelling (eg, "en_US.UTF-8"
where the name we know about is "en_US.utf8"). In general, datcollate
is handled through other code paths than collation names, so it might
easily be that it doesn't match anything in the remote's pg_collation
catalog either :-(.
This is where we got stuck as well (+David who did a lot of digging on this issue). Hence submitting the discovery without our half-baked patch.
We had difficulty finding the place in the code were LC_COLLATE gets recombobulated into a recognized collation.
We had difficulty finding the place in the code were LC_COLLATE gets recombobulated into a recognized collation.
В списке pgsql-hackers по дате отправления
От: Masahiko Sawada
Дата:
От: Peter Geoghegan
Дата: