Hello,
I have a query plan for a certain query
Nested Loop (cost=1.00..38761761090.50 rows=3000608 width=8)
-> Seq Scan on lineitem (cost=1.00..100213649.15 rows=6001215
width=8)
-> Index Scan using oindex2 on myorders (cost=0.00..6442.27 rows=1 width=4)
Inde
> That's not where the problem is. The people who will be left holding
> the short end of the stick are the ones who can't raise their SHMMAX
> setting past a couple of megabytes.
>
> It might be feasible to make pg_stat_activity's max string length
> a postmaster-start-time configuration option.
Tom Lane wrote:
Decibel! <[EMAIL PROTECTED]> writes:
That's not where the problem is. The people who will be left holding
the short end of the stick are the ones who can't raise their SHMMAX
setting past a couple of megabytes.
It might be feasible to make pg_stat_activity's max string length
a
Decibel! <[EMAIL PROTECTED]> writes:
> Also, I don't necessarily buy that 32k * max_connections is too much
> shared memory; even with max_connections of 1000 that's only 32M,
> which is trivial for any box that's actually configured for 1000
> connections.
That's not where the problem is.
On Jun 19, 2008, at 10:26 AM, Alvaro Herrera wrote:
David Miller wrote:
That is fine.. Maybe a dynamic configurable parameter that can be
set/updated while the database is running.
If it were a parameter, it could not be changed while the database is
running.
This issue lies in the fact that
Currently, there is a limitation in PostgreSQL that any ON SELECT RULE must be
an unconditional SELECT action that is INSTEAD.
The reasoning is "This restriction was required to make rules safe enough to
open them for ordinary users, and it restricts ON SELECT rules to act like
views."
I cann
I have been working on a project (for GSOC) to retrieve
planner/optimizer details. As part of the project, I need machine
parsable output. So, I thought I would dust off a patch I found from
last year that Germán Caamaño submitted. I didn't see any further
activity there so I integrated it i
I wrote:
> This is safe if and only if t_isspace is never true for multibyte
> characters ... can anyone think of a counterexample?
Non-breaking space is a counterexample, so I pg_mblen-ified those
loops too. Fortunately this code only executes during dictionary
cache load, so a few extra cycles
I've identified the cause of bug #4253:
/* Trim trailing space */
while (*pbuf && !t_isspace(pbuf))
pbuf++;
*pbuf = '\0';
At least on Macs, t_isspace is capable of returning "true" when pointed
at the second byte of a 2-byte UTF8 character. Thi
David Miller wrote:
> That is fine.. Maybe a dynamic configurable parameter that can be
> set/updated while the database is running.
If it were a parameter, it could not be changed while the database is
running.
> This issue lies in the fact that we have queries larger than 1K and we
> would lik
David Miller <[EMAIL PROTECTED]> writes:
> I would like to request a change to the PGBE_ACTIVITY_SIZE #define in the
> pgstat.h file. This value determines the max length of the SQL query
> contained in the PgBackendStatus structure.
> By increasing the value of this #define to 32768 we are
David Miller <[EMAIL PROTECTED]> writes:
> I would like to request a change to the PGBE_ACTIVITY_SIZE #define in the
> pgstat.h file. This value determines the max length of the SQL query
> contained in the PgBackendStatus structure.
> By increasing the value of this #define to 32768 we are able
I would like to request a change to the PGBE_ACTIVITY_SIZE #define in the
pgstat.h file. This value determines the max length of the SQL query contained
in the PgBackendStatus structure.
By increasing the value of this #define to 32768 we are able to capture queries
larger than the 1024 defaul
Am Donnerstag, 19. Juni 2008 schrieb Tom Lane:
> Making the commutator operator where you need it *is* a general solution.
True. Let me rephrase. The problem is that when dealing with operator names
such as ~~ and &&, coming up with commutator operator names will make a mess
of readability.
>
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I can do
> 'abc' LIKE ANY (ARRAY['a%','b%'])
> but not
> ANY (ARRAY['abc', 'def']) LIKE '%a'
> This seems to be a failing in the SQL standard. You can work around this by
> creating your own operators, but maybe there should be a general solution,
On Thu, Jun 19, 2008 at 11:31:02AM +0200, Peter Eisentraut wrote:
> I can do
>
> 'abc' LIKE ANY (ARRAY['a%','b%'])
>
> but not
>
> ANY (ARRAY['abc', 'def']) LIKE '%a'
>
> This seems to be a failing in the SQL standard. You can work around
> this by creating your own operators, but maybe there s
Hola,
Acabo de firmar una petición pidiendo a los países del G8 que dejen de sabotear el progreso hacia un tratado sobre el cambio climático. Pensé que te interesaría esta campaña:
http://www.avaaz.org/es/g8_climate_wakeup/98.php?cl_tf_sign=1
El futuro de nuestro planeta está en juego en la cubr
I can do
'abc' LIKE ANY (ARRAY['a%','b%'])
but not
ANY (ARRAY['abc', 'def']) LIKE '%a'
This seems to be a failing in the SQL standard. You can work around this by
creating your own operators, but maybe there should be a general solution, as
there are a lot of noncommutable operators and this
Josh,
>> I stated details of proposal on page 2-13, 67-75 of pdf-document
>> http://sql50.euro.ru/sql5.16.4.pdf , and i ask to implement it.
>> All my proposals are public domain.
JB> I'm confused. You're planning to develop this
I can't make this alone.
JB> or you're looking for someone else
19 matches
Mail list logo
