Claudio Freire writes:
> This is postgresql 9.0.3:
> Query:
> select
> sum(stat_responses) * 100.0 / sum(stat_invites) as stat_response_rate,
> sum(real_responses) * 100.0 / sum(real_invites) as real_response_rate
> from (
> select
> ms.invites as stat_invites,
>
On Mon, Mar 14, 2011 at 12:40 PM, Robert Haas wrote:
> Generally, table partitioning is not a good idea unless you are
> dealing with really large tables, and nearly all of your queries apply
> only to a single partition. Most likely you are better off not using
> table inheritance in the first p
On Mon, Mar 14, 2011 at 12:42 PM, Samba GUEYE wrote:
> Yeah but is there a workaround to force the root table to propagate the
> foreign key to the partitionned table
> because right now all foreign keys to partitionned table throws constraints
> violation and it's a big problem for me
No. Gener
Claudio Freire writes:
> CREATE OR REPLACE VIEW member_all_tags_v AS
> SELECT member_tags.member_id, member_tags.last_modification_date,
> member_tags.polarity, member_tags.tag_id, 'mr' AS source
>FROM member_tags
> UNION ALL
> SELECT member_profile_tags.member_id,
>
On Mon, Mar 14, 2011 at 12:46 PM, Claudio Freire wrote:
> On Mon, Mar 14, 2011 at 2:34 PM, Merlin Moncure wrote:
>> changes to:
>>
>> SELECT member_statistics.member_id
>> FROM member_statistics
>> WHERE EXISTS
>> (
>> SELECT mat1.tag_id
>> FROM member_
On Mon, Mar 14, 2011 at 10:54 AM, Claudio Freire wrote:
> Nothing?
>
> No ideas?
>
> Did I forget to include some useful bit?
>
> On Fri, Mar 4, 2011 at 8:22 PM, Claudio Freire wrote:
>> Hello, first post to this list.
>>
>> I have this query that ran in milliseconds in postgres 8.3.7 (usually 50
"John Surcombe" writes:
>> It'd be
>> useful to see the pg_stats.correlation value for both the userid and
>> receiveddatetime columns.
> Yes, the table is indeed nearly perfectly ordered by receiveddatetime
> (correlation 0.998479). correlation on userid is -0.065556. n_distinct
> on userid is
This is postgresql 9.0.3:
Query:
select
sum(stat_responses) * 100.0 / sum(stat_invites) as stat_response_rate,
sum(real_responses) * 100.0 / sum(real_invites) as real_response_rate
from (
select
ms.invites as stat_invites,
(select count(*)
Julius Tuskenis writes:
> From the postgresql documentation about STABLE functions: "This
> category allows the optimizer to optimize multiple calls of the function
> to a single call." I thought that this means that optimizer executes the
> function only for now parameter sets and stores resu
> >> When we 'EXPLAIN' this query, PostgreSQL says it is using the index
> >> idx_receiveddatetime. The way the application is designed means
that
> >> in virtually all cases the query will have to scan a very long way
> >> into idx_receiveddatetime to find the first record where userid =
> 311369
Hello, Merlin
Thank you for your quick response.
2011.03.10 23:14, Merlin Moncure rašė:
This is a huge problem with non trivial functions in the select list.
Pushing the result into and a subquery does NOT guarantee that the
inner result is materialized first.
From the postgresql documentation
Yeah but is there a workaround to force the root table to propagate the
foreign key to the partitionned table
because right now all foreign keys to partitionned table throws
constraints violation and it's a big problem for me
Le 11/03/2011 19:31, Robert Haas a écrit :
On Thu, Mar 10, 2011 at 3:
> Bulk data imports of this size I've done with minimal pain by simply
> breaking the raw data into chunks (10M records becomes 10 files of
> 1M records), on a separate spindle from the database, and performing
> multiple COPY commands but no more than 1 COPY per server core.
> I
Nothing?
No ideas?
Did I forget to include some useful bit?
On Fri, Mar 4, 2011 at 8:22 PM, Claudio Freire wrote:
> Hello, first post to this list.
>
> I have this query that ran in milliseconds in postgres 8.3.7 (usually 50,
> 100ms), and now it takes a full 10 minutes to complete.
>
> I track
On Thursday, March 10, 2011 05:26:00 PM Julius Tuskenis wrote:
> 3) As STABLE function should be executed once for every different set of
> parameters
Thats not true. Thats not what any of the volatility information (like STABLE,
IMMUTABLE, VOLATILE) does.
See http://www.postgresql.org/docs/curr
On Mon, Mar 14, 2011 at 3:46 AM, Julius Tuskenis wrote:
> Hello, Merlin
>
> Thank you for your quick response.
>
> 2011.03.10 23:14, Merlin Moncure rašė:
>
> This is a huge problem with non trivial functions in the select list.
> Pushing the result into and a subquery does NOT guarantee that the
>
On Mon, Mar 14, 2011 at 4:17 AM, Marti Raudsepp wrote:
> On Sun, Mar 13, 2011 at 18:36, runner wrote:
> > Other than being very inefficient, and consuming
> > more time than necessary, is there any other down side to importing
> > into an indexed table?
>
> Doing so will result in somewhat large
On Sun, Mar 13, 2011 at 18:36, runner wrote:
> Tried removing the indexes and other constraints just for
> the import but for a noob like me, this was too much to ask. Maybe
> when I get more experience.
pgAdmin should make it pretty easy. Choose each index and constraint,
save the code from the
18 matches
Mail list logo
