hi
Thanks again very much for these clear-cut answers
I think i'll try to implement the partitionning despite all the
difficulties you raise about it in this thread
because i can't find any viable solution right now for this situation.
It will constrain me to change the datamodel to workaround
On 03/15/2011 05:10 AM, Samba GUEYE wrote:
1. Why "... partitionning is not a good idea ..." like you said
Robert and Conor "... I grant that it would be better to never need
to do that" ?
There are a number of difficulties the planner has with partitioned
tables. Only until very recently, MA
On Sun, Feb 27, 2011 at 2:43 AM, Josh Berkus wrote:
> On 2/25/11 5:31 AM, Sam Wong wrote:
> > I found that "LIKE", "= ANY (...)", "LIKE .. OR LIKE .." against a text
> > field used the index correctly, but not "LIKE ANY (...)". Would that be a
> > bug?
>
> No, it would be a TODO. This is a known
Alright thanks all of you for your answers, but i've got 3 more questions :
1. Why "... partitionning is not a good idea ..." like you said
Robert and Conor "... I grant that it would be better to never
need to do that" ?
2. Is there another way or strategy to deal with very large t
Thank you, Tom for you answer
2011.03.14 19:17, Tom Lane rašė:
That function property*allows* the optimizer to
invoke the function fewer times than would happen in an un-optimized
query. It does not*require* it to do so.
Thank you for clearing that for me. I think these 2 sentences in
docume
Hello,
2011.03.14 15:41, Merlin Moncure rašė:
WITH results as
(
SELECT distinct price_id as price_id
FROM ticket_price
JOIN ticket_has_ticket_price ON (price_id = thtp_price_id)
WHERE price_event_id = 7820 and (current_timestamp>= price_date AND
current_timestamp<= price_date_till)
)
