Greg Stark <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout writes:
>> It's called LIMIT and has been supported for a long time.
> And if I *don't* want to limit the number of rows I retriev?
You still need to do something proactive to inform the system that you
want a fast-start plan. What
I find that libpq.so exports the following symbols that have neither
PQ, pq, pg, nor lo_ as a prefix:
EncryptMD5
SockAddr_cidr_mask
fe_getauthname
fe_getauthsvc
fe_sendauth
fe_setauthsvc
freeaddrinfo_all
getaddrinfo_all
getnameinfo_all
md5_hash
rangeSockAddr
md5_hash seems a particularly unforgiv
On Sun, Oct 16, 2005 at 01:57:13PM -0700, Josh Berkus wrote:
> Martjin,
> > This problem has been around for ever yet obviously not everybody runs
> > into it all the time like I do. Would patch to fix this be accepted or
> > is there a reason why not?
> Actually, I run into it fairly often when I'
Josh Berkus writes:
> Greg,
>
> > Or something like that. It might require breaking random_page_cost into two
> > or three different parameters that would normally have the same cost but
> > aren't handled the same, like random_heap_cost, random_leaf_cost, and
> > random_nonleaf_cost.
>
> Gods
On Sun, 2005-16-10 at 01:20 -0700, Kevin McArthur wrote:
> Don't forget insert/update returning.
Omar Kilani has a patch for this:
http://archives.postgresql.org/pgsql-patches/2005-07/msg00568.php
I would like to see it get into 8.2
-Neil
---(end of broadcast)
Martijn van Oosterhout writes:
> > (I think there really ought to be a bit in the protocol that the client
> > sends
> > with the query to indicate which is needed. That would be cleaner than
> > Oracle's /*+ FIRST_ROW */ and /*+ ALL_ROWS */ hints.)
>
> It's called LIMIT and has been supported
On Sun, Oct 16, 2005 at 05:09:57PM -0400, Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
> > Certainly, if you do not supply a LIMIT, there is no justification
> > at all for expecting the planner to prefer fast-start over
> > minimum-total-cost.
>
> Well figuring out when to prefer one
On Sun, Oct 16, 2005 at 04:06:04PM -0400, Andrew Dunstan wrote:
> Martin,
>
> Let's see the patch. I assume it should be fairly small. If we could get
> it in early in the 8.2 cycle we would have plenty of time to bang on it.
> In principle this sounds reasonable to me, but psql can be broken qu
Kevin,
> I have to keep a very narrow focus on this, or there is likely that
> nothing will come of it. The particular area which is my target
> here is the accuracy of the cost values on the subplans
> considered by the optimizer.
Sure. What the rest of us are focused on is helping you build a
Greg,
> Or something like that. It might require breaking random_page_cost into two
> or three different parameters that would normally have the same cost but
> aren't handled the same, like random_heap_cost, random_leaf_cost, and
> random_nonleaf_cost.
Gods forbid. People don't know how to use
Tom Lane <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout writes:
> > On Sun, Oct 16, 2005 at 12:03:33PM -0400, Greg Stark wrote:
> >> That's true. That's why I was wondering more about cases where the client
> >> end
> >> was going to read all the records until it found the record it's look
Martjin,
> This problem has been around for ever yet obviously not everybody runs
> into it all the time like I do. Would patch to fix this be accepted or
> is there a reason why not?
Actually, I run into it fairly often when I'm being hasty. I'd imagine most
Linux-based newbies do as well.
--
Jari,
> Comparison of different SQL implementations
> http://troels.arvin.dk/db/rdbms/ by Troels Arvin <[EMAIL PROTECTED]>
Should be pretty up to date. Troels often pops into IRC to see if we have any
news for him.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---
[ resuming an old thread ]
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> I also tried different settings (shmall set to 500K) and shmmax ended up at
> -1. So, it seems that shmall is in pages. I didn't try other allowable
> configs, which was a problem before.
I went back and experimented some
Martijn van Oosterhout wrote:
The point is, less is still running but psql it pulling the keystrokes
from under it... When you finally quit less it does restore the
settings, but now readline doesn't expect that as it's changed them
again...
Martin,
Let's see the patch. I assume it shou
On Sun, Oct 16, 2005 at 02:44:41PM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > This problem has been around for ever yet obviously not everybody runs
> > into it all the time like I do. Would patch to fix this be accepted or
> > is there a reason why not?
>
> I guess everybody els
Martijn van Oosterhout writes:
> This problem has been around for ever yet obviously not everybody runs
> into it all the time like I do. Would patch to fix this be accepted or
> is there a reason why not?
I guess everybody else uses "q" not control-C to get out of less ;-)
I'm not sure I agree
Greg Stark <[EMAIL PROTECTED]> writes:
> The example above raises another idea though. Would it be possible for the
> optimizer to recognize when a clause is so expansive that it would be faster
> to read the complement than the actual clause as written?
Being able to compute the complement, much
[EMAIL PROTECTED] wrote:
These "fake signals" are dispatched on the main thread. They are
received by a worker thread, which will queue them up and set a flag,
and the main thread then polls this queue and delivers the actual
signal.
OK. Now I understand. On Windows I don't need to do anything
Martijn van Oosterhout writes:
> On Sun, Oct 16, 2005 at 12:03:33PM -0400, Greg Stark wrote:
>> That's true. That's why I was wondering more about cases where the client end
>> was going to read all the records until it found the record it's looking for
>> or found enough records for its purposes.
[EMAIL PROTECTED] wrote:
Hi,
I'm in the process of securing the PL/Java signal handling routines.
Since a multi-threaded JVM is running and a signal can occur
at any time in any thread, I need to trap some of them and
make sure that they are executed in the main thread. Using
Posix signals, t
On Sun, Oct 16, 2005 at 12:03:33PM -0400, Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
> > Another point here is that LIMIT without any ORDER BY isn't an amazingly
> > useful case. Neither the old implementation of OR indexscans nor the
> > new can produce ordered output, which means y
> Hi,
> I'm in the process of securing the PL/Java signal handling routines.
> Since a multi-threaded JVM is running and a signal can occur
> at any time in any thread, I need to trap some of them and
> make sure that they are executed in the main thread. Using
> Posix signals, this is easy. He
Tom Lane <[EMAIL PROTECTED]> writes:
> If the fraction of records matching the IN-list is so large as to make
> that an issue, I'd think the planner would prefer a seqscan anyway.
> Besides which, it's a bit silly to worry about whether a plan is
> fast-start without taking into account the amount
Hi,
I'm in the process of securing the PL/Java signal handling routines.
Since a multi-threaded JVM is running and a signal can occur at any time
in any thread, I need to trap some of them and make sure that they are
executed in the main thread. Using Posix signals, this is easy. Here's a
samp
This behaviour has been around so long that I've gotten used to it but
I've always considered it a bug. Yet it has never been fixed so I'm
going to ask if anybody else has issues with this behaviour.
Reproducing it is easy:
1. Set PAGER=less
2. Start psql
3. Type: \df
4. When output appears, hit
On Sun, Oct 16, 2005 at 01:20:45AM -0700, Kevin McArthur wrote:
> Don't forget insert/update returning. With the deprecation of OID's this
> functionality is becoming more and more important when using custom types
> and column defaults.
I use currval/nextval and have never actually needed such a
On Sat, Oct 15, 2005 at 06:48:25PM -0400, Tom Lane wrote:
> > So, what's good for battery and power usage is bad for accurate
> > timings. Basically, on Linux it would seriously underestimate the time
> > for blocking system calls on an otherwise idle system. So, it works for
> > Windows because th
While I searched SQL information I ran into page that discusses
database management systems and their standards compliance and to my
satisfaction PostgreSQL scored high in this evaluation.
As there is always room for improvements, perhaps the development team
could read this document and record s
Don't forget insert/update returning. With the deprecation of OID's this
functionality is becoming more and more important when using custom types
and column defaults.
Some method for plpgsql to handle the result sets returned and save to a
variable would be important for this feature too. Select
30 matches
Mail list logo
