On 22.11.2012 02:53, Jeff Janes wrote:
That gives the planner the information it needs to choose the right plan on
its own. That kind of hints would be much less implementation specific and
much more likely to still be useful, or at least not outright
counter-productive, in a future version with
On 22.11.2012 09:54, Eildert Groeneveld wrote:
ok, I did have a look at the libpq librar, and you are right, there is a
way to obtain binary data from the backend through the PQexecParams
res = PQexecParams(conn,
"DECLARE myportal CURSOR FOR select genotype_bits
fro
On 11/15/2012 05:02 PM, Sergio Mayoral wrote:
>
> PQconnectdb is taking too long comparing to mysql and i found out the
> time is consumed by PQconnectPoll waiting for the socket to be ready
> for reading/writing
What's "too long"?
>
> I cannot use persistent connections. I must open/close a connec
Hello,
This is a performance question that has held me occupied for quite some
time now,
The following join is a somewhat slow query:
(np_artikel, sm_artikel_dim are views and sm_orderrad_* are tables )
xtest=# explain analyze verbose
select * from np_artikel np
join sm_artikel_dim dim on n
On 22/11/2012 00:08, Craig Ringer wrote:
WITH
FENCE foo AS (SELECT ...),
bar AS (SELECT ...)
SELECT * FROM bar;
Are we fencing just foo? Or all expressions?
WITH foo AS (FENCED SELECT ...),
bar AS (SELECT ...),
SELECT ... ;
--
Jeremy
--
Sent via pgsql-performance mailing list
On Thu, Nov 22, 2012 at 7:42 AM, Jeremy Harris wrote:
> On 22/11/2012 00:08, Craig Ringer wrote:
>>
>> WITH
>>FENCE foo AS (SELECT ...),
>>bar AS (SELECT ...)
>> SELECT * FROM bar;
>>
>> Are we fencing just foo? Or all expressions?
>>
>
> WITH foo AS (FENCED SELECT ...),
> bar AS (SEL
I'd also add ANALYZED/NOT ANALYZED. This should force it behave like
'create table, analyze, select' with statistics used in second query plan.
P.S. defaults can be configurable.
20 лист. 2012 02:22, "Gavin Flower" напис.
> On 15/11/12 15:03, Peter Geoghegan wrote:
>
>> On 15 November 2012 01:46
