Jean-Michel =?ISO-8859-1?Q?Pour=E9?= writes:
> What do you recommend: using normal types and moving constraints in the
> Drupal database? Is PostgreSQL domain broken as it forces casting or is
> this a no-op for performance?
In principle it should be an unnoticeable slowdown. In the past we've
h
Le samedi 29 août 2009 à 13:44 -0400, Tom Lane a écrit :
> That domain doesn't have any operators of its own. To compare to
> another value, or use an index, you have to cast it to integer which
> does have operators. It's a no-op cast, but logically necessary.
Dear Tom,
Thanks for answering. O
Jean-Michel =?ISO-8859-1?Q?Pour=E9?= writes:
> In Drupal database, we have two types:
> CREATE DOMAIN int_unsigned
> AS integer
> CONSTRAINT int_unsigned_check CHECK ((VALUE >= 0));
> Why do queries cast between integer and int_unsigned?
That domain doesn't have any operators of its own. To c
Le samedi 29 août 2009 à 11:16 -0400, Bruce Momjian a écrit :
> > Why is the query planner displaying ::integer
> > What does it mean?
>
> ::integer casts a data type to INTEGER. It is the same as CAST().
In Drupal database, we have two types:
integer
int_unsigned
CREATE DOMAIN int_unsigned
Jean-Michel Pour? wrote:
-- Start of PGP signed section.
> Le jeudi 27 ao?t 2009 ? 14:05 -0400, Tom Lane a ?crit :
> > tom lane
>
> Dear Tom,
>
> Why is the query planner displaying ::integer
> What does it mean?
::integer casts a data type to INTEGER. It is the same as CAST().
--
Bruce Mo
Le jeudi 27 août 2009 à 14:05 -0400, Tom Lane a écrit :
> tom lane
Dear Tom,
Why is the query planner displaying ::integer
What does it mean?
Kind regards,
Jean-Michel
signature.asc
Description: Ceci est une partie de message numériquement signée
Le jeudi 27 août 2009 à 13:35 -0400, Robert Haas a écrit :
> SELECT MIN(tid), MAX(tid), SUM(1) FROM term_node;
> SHOW default_statistics_target;
SELECT MIN(tid), MAX(tid), SUM(1) FROM term_node;
6;56;67479
SHOW default_statistics_target;
100
For information, if some hackers are interested and th
Robert Haas writes:
> By the way, why does EXPLAIN not display the name of the table as well
> as the index when it performs a bitmap index scan?
Because that plan node is not in fact touching the table. The table
name is shown in the BitmapHeapScan node that *does* touch the table.
2009/8/27 Kevin Grittner :
> It is *possible* that if you boost your default_statistics_target and
> run ANALYZE (or VACUUM ANALYZE), it will recognize that it isn't a
> good idea to read backwards on that index. I would try it and see, if
> that's practical for you.
I notice this in one of the p
Jean-Michel Pouré wrote:
> Also, just a short notice that this SELECT returns no result.
Once you posted EXPLAIN ANALYZE results, that was clear because actual
rows on the top line is zero.
> You were right: adding LIMIT 1 changes speed from O.090 ms to 420
> ms.
In summary, what's happenin
Dear Kevin,
Thanks for help!
Could you run this?:
>
> set work_mem = '50MB';
> set effective_cache_size = '3GB';
> EXPLAIN ANALYZE
> begin transaction;
> drop index node_comment_statistics_node_comment_timestamp_idx;
> EXPLAIN ANALYZE
> rollback transaction;
set work_mem = '50MB';
set effect
Le mercredi 26 août 2009 à 18:03 -0500, Kevin Grittner a écrit :
> That's part of your problem.
Sorry, I wrote that too quickly.
My configuration is (Quad core, 8Gb):
shared_buffers = 2GB (WAS 1GB)
temp_buffers = 128MB (modified after reading your message)
work_mem = 512MB (modified after readin
I wrote:
> I will take another look at it now that you have the results of
> EXPLAIN ANALYZE posted
Could you run this?:
set work_mem = '50MB';
set effective_cache_size = '3GB';
EXPLAIN ANALYZE
begin transaction;
drop index node_comment_statistics_node_comment_timestamp_idx;
EXPLAIN ANALYZE
Jean-Michel Pouré wrote:
> [no postgresql.conf changes except]
> shared_buffer 24M.
That's part of your problem. (Well, that's understating it; we don't
have any real evidence that you have any performance problems *not*
resulting from failure to do normal configuration.) If you download
the
Dear friends,
I contact on Postgresql hackers request.
I am running into a systemic
problem using Drupal under PostgreSQL 8.4
Drupal relies heavily on a domain derived from int:
CREATE DOMAIN int_unsigned
AS integer
CONSTRAINT int_unsigned_check CHECK ((VALUE >= 0));
Analysing slow querie
15 matches
Mail list logo
